"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.
.
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 Gliimly
If there is a fatal internal error (i.e. error in Gliimly code itself that cannot be handled), it will be caught by Gliimly, 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 logged and the program stack with full source code lines (see gg for including debug information) will be written to backtrace file (use -e option of gg to obtain its location). Note that the program stack is logged only if Gliimly is built in debugging mode (see "DI=1" option when building Gliimly); otherwise, production code may be slowed down by stack dumping.
You can see the list of last N errors (and the location of file containing backtrace for them) by using gg, for instance to see the last 3 errors:
