`WebServer` failed to trigger debugger

[dram]

According to the doc, following code will make WebServer trigger debugger on error, but it does not work:

server := WebServer new.
server listenOn: 8080.
server addService: '/' action: [:request | 1 / 0].
server errorHandler: [:error :request | error pass].

Run code in Workspace, and visit http://127.0.0.1:8080/ in browser, it just failed silently.

[dram]

Seems that Error is captured in several other places in WebServer besides WebServer>>#dispatchRequest:url:, so although pass is called for error in the errorHandler, this error will be captured in some other methods which do not respect errorHandler setting.

To bypass this problem, I changed errorHandler to following, which seems to work:

server errorHandler: [:error :request | UnhandledError signalForException: error].

[codeZeilen]

This is a hard one, as the whole server process setup assumes that on errors that are not handled by either the default or the user-specified error handler, or any of the network handling logic, are so severe that the server process needs to terminate.

As a workaround it is possible to open a debugger explicitly via:

server errorHandler: [:error :request | ToolSet debugException: error]

Instead of changing the infrastructure, we might want to consider changing the documentation.

Opinions @marceltaeumel @krono ?

[krono]

handleConnectionFrom: might simply need an ex pass??

     ] on: Error do:[:ex|
        (ex isKindOf: NetworkError) ifFalse:[
            self log: 'Error in request handling: ', ex description.
            self log: (self errorReportFor: ex).
        ].
                ex pass. "<----"
    ].

But asyncHandleConnectionFrom: is harder, as the Hanlder destroys the socket:

        [ [ self handleConnectionFrom: aSocket ] 
            on: Error do: [ :ex | aSocket destroy ] "..."

Yet, as far as I can see, these are the only two places.

[codeZeilen]

The second one is the one I was refering to with "so severe that the server process needs to terminate". I guess the intent was to have this running without user interventions and thus this makes sense. Supporting interactive debuggers would require a somewhat different setup of the server process.