# Handling Exceptions

As a matter of principle, you should try to handle all exceptions as close to their source as possible. However, sometimes that's not practical, or just too verbose. In that case, Handy-Httpd provides a safeguard for you: the ServerExceptionHandler. Each HttpServer has a single exception handler, which is responsible for dealing with any uncaught exceptions that make their way to a worker thread's main logic.

By default, all servers are configured to use the BasicServerExceptionHandler, which is set up to handle HttpStatusExceptions gracefully by setting the response's status accordingly, and for all other exceptions, logs an error message and returns a 500 Internal Server Error response (if the response headers haven't been flushed yet).

You can add your own exception handler like so:

class CustomExceptionHandler : ServerExceptionHandler {
    void handle(ref HttpRequestContext ctx, Exception e) {
        import std.stdio;
        writeln("Oh no!");

HttpServer server = new HttpServer(myRequestHandler, myConfig);
server.setExceptionHandler(new CustomExceptionHandler());

Again, as a matter of principle, your exception handler should do as little as possible, and it should not throw any exceptions itself, if you can help it. Any errors that occur inside an exception handler itself will be logged, and no further action can be taken.

Consider having your custom exception handler extend from BasicServerExceptionHandler, so you can simply override its handleOtherException method, while allowing it to handle HttpStatusExceptions for you. Otherwise, you'll probably need to build your own logic for handling HttpStatusExceptions.

# Fatal Errors

It's rare, but you may encounter fatal errors while handling a request, to the tune of segmentation faults, out-of-memory errors, or concurrent modification issues. In such cases, the worker thread that handled that request will die immediately, and the client may or may not receive a coherent response.

Handy-Httpd will try and resurrect dead workers periodically, and it'll warn you each time it does, but it's recommended that you try and address the underlying cause instead of relying on brute-force thread resurrection.

⚠️ D programmers are discouraged from catching Error or any subclass of it. Most errors are a symptom of unsafe code.