@sandervlot
This is a consequence of how pro::DelegateToServer is handled. When you use pro::DelegateToServer in a procedure, that procedure will be re-run in a solver session (with all the current arguments), using the current data in the current session.
Within the solver session, the procedure will be run from within the context of pro::OptimizeCurrentCase inside a block-on-error, by handling an incoming message that encodes the original procedure call with arguments on the client side. Handling that message means, re-running the procedure call encoded in it.
The block-on-error is necessary to allow pro::OptimizeCurrentCase to not be interrupted, such that it can communicate back the result to the client, even in case of an error. If the error would fall through completely to the global error handler, the call to pro::OptimizeCurrentCase would not be able to complete.
So, if you use a global error handler e.g. to record any error to a logging table, then you will have to call this procedure yourself inside a block-on-error for this to work inside a solver session, as you illustrated in your example. In fact, you're not really using the global error handler then as the final means to catch errors that would otherwise have fallen through and resulted in a runtime error, but (misusing it) as a means to log anything that goes wrong.
Hope this clarifies.
