should recovery middleware write a error page?

I took a look at a few big frameworks and I noticed that recovery middleware only writes 500 instead of writing a error page.

For example gogs uses the macaron framework [1]. The macaron recovery handler only writes the header with a 500 status code [2]. Or gin [3]

Initially I thought that an error page would make more sense, as there is some actual html for clients to know something went wrong. But even gogs only writes a 500, no error page. I'm not so sure anymore.

[1] https://github.com/gogits/gogs/blob/master/cmd/web.go#L106

[2] https://github.com/go-macaron/macaron/blob/master/recovery.go#L154

[3] https://github.com/gin-gonic/gin/blob/develop/recovery.go#L42

edit: to clarify I mean a page that says something like "something went wrong, but don't worry, the monkeys are on the case" in some nice typography.

You shouldn't write error details out to the error page -- unless, by "error page" you simply mean a custom page that looks nice, rather than plaintext "Internal server error"... error details can sometimes contain sensitive information that makes it easier for attackers to exploit your system.

Anyway, in Caddy how we handle this is we log the error (and/or stack trace, if applicable) to the error log. This is not public and allows the website owner to get the full details of the error. Caddy can serve a custom error page that looks pretty, or if you don't set one, it writes a simple, generic plaintext error message.

The exception is if you specifically turn on error details in the response; in this case, Caddy will write out the error details to the error page -- this is useful in local testing/dev situations when you don't want to keep looking at your log, and you just want to see the error when you load the page. However, as I said, this is a bad idea in production.

To answer your question: Yes, I prefer that web apps write error pages that look nice, but they shouldn't contain error details.

of course I didn't mean write the stack trace or any error details at all to the client. Just a nice simple generic page.

A panic should be an indication of an exceptional problem.  Log the issue and send out the most basic of messages in a sure-fire way.

Otherwise, if something occurs like an err returned from json.Marshal(), I have a helper function which logs the issue and prints an HTML version of the basic error message.

Remember, not every web server is used to serve user-facing content, and not every web server is used to serve HTML. It would be strange for a JSON API to spit out HTML in the case of an error. The plaintext that results from only writing a header isn't a lot better, though. I haven't looked at the specific cases you're talking about, but it would make sense to be able to define what content is sent.

This