Here is one benefit of installing a custom error handler that perhaps isn't as widely appreciated as it should be:

The default behavior of 4D, when a system-level error occurs, is to immediately terminate the code for the entire current process. The effect is the same as if you had clicked the Abort button in the 4D Debugger window. 4D cannot be sure if it can safely proceed after the error condition, so it terminates code execution rather than risk damaging your data. You can prevent premature termination of your code by using the ON ERR CALL command to install a custom error handling method. Then, it is your responsibility to write code that responds appropriately to an error condition before continuing.

In you are using stored procedures to execute code on the server, it is critically important to use a custom error handler. Otherwise, any error messages will display a modal dialog on the server computer. Until someone goes to the server computer and clicks the "OK" button to close this alert dialog, all connected 4D Clients are frozen.

To prevent this problem of "freezing" the clients, you can suppress the display of error dialogs on 4D Server by installing your own error handling method. The best way to do this is to use the ON ERR CALL command in the On Server Startup database method. You may be used to error handling on 4D standalone and 4D Client, where each process has its own error handling method. But on 4D Server, all triggers and several of the database methods share one error handling method. Installing the error method in the On Server Startup method also installs that error method for all of 4D Server's triggers as well. If you choose to suppress the display of error alerts this way, your code still needs to provide some sort of graceful handling for the error condition itself.

This behavior of 4D where it terminates code execution upon encountering an error is fully documented in the 4D Language Reference Manual under the description of the ABORT command.