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 _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus