[Lazarus] How do Lazarus users handle exceptions in procedures which are running in data modules?

[Hans-Peter Diettrich]

Frank Church schrieb:
> How do Lazarus users handle exceptions in procedures which are running
> in data modules?
> 
> A lot of the guides and examples demonstrate raising exceptions, which
> generally display dialogs to the user that an exception has occurred.

Sample code showing an error message is *not* useful in real life 
exception handling, because Application will do that for you and show 
the error message.

> But what is the best way to handle them if they occur inside data
> modules as they may not have a user interface, or are even not
> supposed to have any, but then somehow communicate the exception back
> to the user interface is required?

Exceptions are not intended for immediate handling. Instead an exception 
should be handled in a place where it can be handled in a *meaningful* 
way, somewhere up in the call stack. Only if you have a loop or a 
sequence of statements, which should continue even if something goes 
wrong in on statement or iteration, you catch exceptions there.

In a sequence of statements you have to enclose every error prone 
statement with an try-except block or, when the statement is a call, 
enclose the code in that subroutine. In the exception handler you can 
set variables to meaningful values, to keep the code following the 
try-except block working. This can obviously be done only in places 
where you know about the following statements, and how they should 
behave after an exception has occured.

In a loop you enclose the entire loop body with try-except, and issue a 
message like "in ... iteration #... failed due to ...", or whatever the 
user should know. You also can set a flag and report "some iterations 
failed..." after the loop.

Of course not all exceptions can be handled this way. Some may be fatal, 
others may be neglectable to some degree. Therefore only selected 
exceptions should be handled in an except block, i.e. those which do not 
prevent the following code from working. The unhandled exceptions can be 
handled in subroutines further up in the call stack, when such handling 
is possible there. This means that exceptions should have specific 
types, which can be recognized in different levels of application 
exception handling.

DoDi