Servers handle requests from clients until terminated deliberately by a server administrator. A client request that results in an uncaught server-side exception causes the current server response generation to fail, and should not have an effect on subsequent client requests.

Under some circumstances, uncaught exceptions can however cause the entire server to terminate abruptly. Such a behavior is highly undesirable, especially if it gives malicious users the ability to turn off the server at will, which is an efficient denial-of-service attack.

Ensure that the processing of client requests can not cause uncaught exceptions to terminate the entire server abruptly.

The following server implementation checks if a client-provided file path is valid and throws an exception if the check fails. It can be seen that the exception is uncaught, and it is therefore reasonable to expect the server to respond with an error response to client requests that cause the check to fail. But since the exception is uncaught in the context of an asynchronous callback invocation (fs.access(...)), the entire server will terminate instead.

To remedy this, the server can catch the exception explicitly with a try/catch block, and generate an appropriate error response instead:

An alternative is to use an async and await for the asynchronous behavior, since the server will then print warning messages about uncaught exceptions instead of terminating, unless the server was started with the commandline option --unhandled-rejections=strict: