Error handling

When your program errors out

"Erroring out" means a process handling a request has encountered a difficulty that cannot be handled and it will either:

Skip the rest of the request, and move on quickly to handle the next request without exiting. Most errors are like this, for example your program has attempted to access memory outside of what's allocated, or you have called report-error statement.
Stop and exit, and it may be automatically restarted if it's a service. For instance, the process could be out of memory, or the database is permanently down and connection cannot be re-established, or there is an internal error.

.
Note that if your program is command-line, it will exit in any case since it handles a single request anyway.

When there is a problem in Golf

If there is a fatal internal error (i.e. error in Golf code itself that cannot be handled), it will be caught by Golf, and the process will end. If your process is started with mgrg, it may be automatically restarted.

Logging the error

Regardless of the type of error and regardless of whether the process exits or not, the error is output to the standard error stream along with the error details: cause of error and full stack trace (including source file names and line numbers); note that for report-error error details are not output since you're providing your own details.

Output when error happens

When your program errors out, a generic message is output to the standard output, i.e. to the client, that indicates that error has occurred, and to check the error log. The actual details are output to standard error stream, see details above. Note that in case of fatal error (such as Golf internal error), no message is sent to the client; rather the program ends. On how to view the error log (including the stack traces), see debugging.