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

[Marcos Douglas]

On Wed, Mar 6, 2013 at 5:44 AM, Antonio Fortuny
<a.fortuny at sitasoftware.lu> wrote:
> Le 05/03/2013 16:14, Frank Church a écrit :
>
>> 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.
>>
>> 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?
>>
>> In my view it is either by passing a var parameter to the procedure in
>> the data module which returns some information about the error, or
>> changing the procedure into a function and return info about the error
>> in the result. On the other hand using functions messes up the reading
>> of the program because it make the return values appear to be the
>> subject of the computations.
>
> Right. This is why I decided once for all to report errors AND return values
> on a function call. I use the following proto:
> function DoingSomething(const arg1: type;...; out Msg: String): Boolean (or
> whatever the result should be). This assumes, of course, that the function
> returns some meaningfull information when everything runs well and a
> predefined error value otherwise (I often use -1 in case of integers). The
> OUT argument Msg will be used by the function to explain why the thuction
> failed and will be empty if the function works OK. The Msg out parameter
> could be whatever you need, not olny a string.
>
>>
>> What are the best practices in Lazarus or Delphi with dealing with
>> this kind of situation? Are there some frameworks for handing this
>> type of problem?
>
> The only rule that I always apply concerning exception handling is to
> process the exception depending on if the concerned code is playing in the
> data layer or the presentation layer. Said in other words, do I play with
> data or the user interface ?
> Obviously, in a DM you are in the data layer.
> Rule: in data layer push exception results (re-raise the exception for
> instance) to the caller whereas on presentation layer, display the exception
> to the user and ask him what action to do next. In any case I never mix data
> and presentation layers processing. This also means that data layer is never
> affected by what happens in the presentation layer and vice-versa except by
> the natural ways: functions, procedures and object properties and methods.

IMHO if you always functions that have a boolean result and an output
message parameter, you do not uses the power of Exceptions.
Depends, depends... but you can use some public methods with boolean
results but the private methods raises an exception if something was
broken, then you catch the exception - that you know what this is
because this is your code - and returns True/False in the public
method.

In many cases I have an Exception type for each unit and one for each
class that inherited from this global type unit.

Marcos Douglas