[Lazarus] Exception dialog

[Martin Friebe]

Michael Van Canneyt wrote:
>> If a component throws an exception outside any call  from your code 
>> (which you can place in a "try except end"), a place like OnDataReceived 
>> which is triggered automatically, then this component has a bug (IMHO).
>> The component *should* have something like an OnError event on which it 
>> can call your code. Or it should have a flag/state, on which it said 
>> that an error occurred.
>> An Exception may be, if an OnError event is provided, but not assigned.
>>     
>
> Why ? 
>
> In the OnValidate event of a TField, you are supposed to throw an exception 
> to stop the user from entering wrong data in the field. This exception can 
> only be caught by the program event loop. This is so by design, and the
> recommended way by Borland.
>
>   
I have to admit, I have limited knowledge of the exact details of the 
data-aware components, and rather was making a general case about my 
perception of proper exception use.
I just googled  => can you point me to some documentation on it?

Following you description, I have no problem if an OnValidate allows the 
code to use an exception to signal the component some-error state.
IMHO the component should have a well defined behaviour on getting this 
exception.
and IMHO the component should then handle it instead of passing it on 
(that may require the exception to be of a defined class, so the 
component knows that the exception is meant for the component)

I wonder what the benefit of passing such an exception to the main-loop is?

If I want to do anything else (anything except signalling the component 
/ anything like informing the user....): It would be far easier to do 
this where I detect the problem (in the OnValidate Method).
Example: different TField.OnValidate may point do different onValidate 
handlers. each knows what to tell the user, and which options to present 
to the user.
- If they throw an Exception to stop the Component from writing to the 
DB => fine
- If they throw an exception, to have the mainloop handling the 
user-error => that would mean, they have to pack all the information 
required for error handling into the exception? Why bother, if you can 
handle the exception locally?

There would be a benefit, if you want to handle exceptions from various  
OnValidate handlers in one place. Then you could use an exception-class 
that is not caught by the component. BUT  then it was your decision that 
the exception should go to the main class. It would not be a default

Anyway, the point is, if we are looking at the original source of the 
discussion (the build-in exception dialog) => that is at best the most 
limited case of handling an exception (It is simply displaying it). It 
does not check any need for cleanup, or other actions, or user-help 
...... So then you would want to use Application.OnException or similar.


The point with the build in dialog is. that even for Exceptions that 
have otherwise been handled (like try/finally) and that only need to be 
displayed. This should be done by your own code, or the Exception should 
in some other way be marked as "handled, display needed only".
Otherwise if you relay on the build-in dialog to do this work for you, 
you mix up 2 crucially different cases:
1) The just described display-only exception => which wants an "OK" 
button only
2) Any exception that occurs, that was not expected, and eaves the 
application potentially unstable. => Which should warn the user, to save 
his work, and quit the app asap. And that should display a "terminate 
app now" button