Hello,

Is there a reason why the default exception dialog has a cancel button to kill the application ?

We often use an exception to signal wrong entry of data or so, because it stops all further processing.

If the user then uses the cancel button, the program is simply ended, which is not what we (or better: the users) want. And I imagine many others use this technique.

I have overridden the OnException handler of TApplication, so it's no longer a problem, but I was curious as to why this is done like this by default ?

Michael.

This is strange for me too and I also often clicked cancel to just cancel that notification but it closed my application :) I suggest to replace it with simple notification dialog with one button (like ShowMessage).

Best regards,
Paul Ishenin.

Michael Van Canneyt wrote

Is there a reason why the default exception dialog has a cancel button to kill the application ?

I have been wondering that for 5 years (since I moved from Delphi), but was to shy to ask. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Oh, good point to discuss about the use of exceptions.

I use exceptions only for really "unexpected" things. That a user will sometimes input wrong data must be expected by a programmer so I do not treat this as an exception.

With unexpected things I mean all the things that are outside my code.
e.g.
  try
    FExcel := GetActiveOleObject('Excel.Application');
  except
     //do something
  end;

Samuel Herzog wrote

> Oh, good point to discuss about the use of exceptions. I use exceptions only for really "unexpected" things.

Well, Borland introduced specially the 'Abort' exception to let the programmer 'jump out' of routines in case of need. It's never shown, but execution continues as the event loop is further handled...

Michael.

Michael Van Canneyt ?????:

I remember discussions on this topic long ago. It was like GTK (GTK 1 at that time) isn't tolerant to exceptions that occur in its signal handlers (read: in LCL and user's code), and it wasn't possible to expect program stability after an exception was raised. That explains the need for 'terminate' button.

The things may have changed since then, however.

Regards,
Sergei

Terminating application on exception is useful sometimes too, so please do not drop this functionality. I agree that it should not be the default.
I suggest to rename buttons "Continue" and "Terminate", with first being _both_ default and "cancel",
so neither pressing "Enter" not "Esc" would terminate application.

Is there a reason why the default exception dialog has a cancel button to kill the application ?

An unhandled exception IMO is due to some software bug, which the user cannot cure in any way.

We often use an exception to signal wrong entry of data or so, because it stops all further processing.

That's okay, if you also implement appropriate exception handling. Exceptions are fine in error situations, that cannot be cured at the place of their occurence. It's up to the program designer to find the best place for handling every intentional exception.

If the user then uses the cancel button, the program is simply ended, which is not what we (or better: the users) want. And I imagine many others use this technique.

No, hopefully not :-(

I have overridden the OnException handler of TApplication, so it's no longer a problem, but I was curious as to why this is done like this by default ?

Insert your exception handler in an more appropriate place, depending on the concrete application. The user can expect a diagnosis of what went wrong, and a chance for correcting his preceding input.

DoDi

En/na Hans-Peter Diettrich ha escrit:

Insert your exception handler in an more appropriate place, depending on the concrete application. The user can expect a diagnosis of what went wrong, and a chance for correcting his preceding input.

For data aware components (and probably for others too), Application.OnException is the only place, otherwise you cannot trap exception that are no caused by your program flow but by intrinsic processing by the component (e.g. during post the database could reject the data due to failed constraints, you could trap BeforePost or AfterPost but not DuringPost).

Bye

That's a very restrictive definition of exception. An exception is a way to stop the normal logic and flow of the program. In a GUI application, you rely on the program's event loop to catch the exception (so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception.

Borland explains this use in detail in chapter 14 of the Delphi 7 manual.

Michael.

while i tend to agree wholeheartedly with both side, i have to suppress a LOL at the last statement because this ain't borland's code or definition of "pascal" in any flavo(u)r... this is FPC's definition and even moreso, lazarus' definition at least as far as lazarus is concerned with the code that it compiles ;)

hopefully that's taken in the spirit it is offered from an old TP2/TP3 coder :)

ACK. And try-except clauses are the way to catch exceptions.

In a GUI application, you rely on the program's event loop to catch the exception

I never did so, for my own or otherwise expected exceptions.

(so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception.

Please don't confuse exception catching and handling. Only catching exceptions can (mostly will) leave the application in an invalid state, so that an abort is the only reasonable "handling".

DoDi

Michael Van Canneyt wrote

Borland explains this use in detail in chapter 14 of the Delphi 7 manual.

Or chapter 13 in the Kylix 3 Developers Guide. ;-) [...at least I still have one use for Kylix... It's help files and documentation.]

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

there is a different between an "unhandled exception" and an "exception"

An exception is indeed a very valid thing, that can and maybe should occur within many applications. But any exception should have some code, that handles it.
And this handling code should not be the build-in Lazarus-exception dialog. Because the build-in dialog does not know what the exception meant and what should be done. It could not clean-up, it could not make sure that any memory allocated and referred only by local variables is freed.

So an *unhanded* exception is a software bugs. an unhandled exception in most languages will simply crash the application. The fact that a Lazarus app does ask the user, if he wants to try and continue (and maybe be able to save his work) is a benefit.
But never the less ending up there is a bug. The user doesn't know if he hit an exception for which the programmer intended to fall back on the build-in dialog (and therefore that the app will still run stable); or if this was an exception the programmer did not foresee, and the app will no be unstable, more exceptions may happen, data be corrupted.....

"In a GUI application, you rely on the program's event loop" .... Well, in my very personal opinion: This is just a bad design idea. If I throw an exception, I write a handler for it.

Best regards
Martin

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.

Best Regards
Martin

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.

Michael.

You cannot always do so. See the TField.OnValidate example in my other mail.

And if Borland designed it so, why not use it ?

Michael.

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).

ACK. Asynchronous operations never should throw exceptions, breaking the control flow of the main application in unrelated places.

DoDi

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

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.

Even Borland is not fail-safe ;-)

DoDi

Please note, I don't use db-aware components, but here follows the help from Kylix 3.

==========[ Kylix 3 help ]================
OnValidate event (TField)
-------------------------
Occurs just before the data is written to the record buffer.

Delphi syntax:
property OnValidate: TFieldNotifyEvent;
C++ syntax:
__property TFieldNotifyEvent OnValidate = {read=FOnValidate, write=FOnValidate};

Description

Write an OnValidate event handler to validate changes made to the data in the field, just before the data is written to the current record buffer. The EditMask property allows validation of the data on a character by character basis while it is being entered by the user. OnValidate allows an application to validate the data as a whole.

When the value of a field component is assigned programmatically, validation by the EditMask is bypassed, since there is no data-aware control to enforce adherence to the mask. OnValidate allows an application to validate such data before it is posted to the database table.

To reject the current value of the field from the OnValidate event handler, raise an exception.

When writing the value of a field to the current record buffer, the following steps occur:
1. The OnValidate event handler is called to validate the data.
2. If the OnValidate event handler does not raise an exception, the data is written to the current record buffer.
3. If writing the data does not raise an exception, the OnChange event handler is called to allow a response to the change. ==========================

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

In the case of the TField.OnValidate, I tend to agree with you. I would image that to stop the system from writing data to the db you need to raise a more specific exception like a custom EMyAppValidationError instead of simply Exception. That way you can display it correctly in the Application.OnException with a simple OK button. Anything else "unknown" can use the default dialog - which signifies that the system is now in a possible unstable state. For the latter, application termination is probably the best choice for the user.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

.....

To reject the current value of the field from the OnValidate event handler, raise an exception.

Then to me the Delphi/Kylix implementation is flawed. Because it forces me to do TWO things, even if I want to do only one of them. There should be:
- an ExceptionClass TDataValitaionException (or whatever) which can be used to abort writing the data, but not defer error handling to the mainloop
- any other exception, that aborts the write, and transfers error handling to the main loop

There are usages for both scenarios, so they should both be possible.

Best Regards
Martin

This may be so, but given the implementation as it is in Delphi, hopefully you can now understand my problem with the Lazarus exception dialog :-)

Michael.

Yes, and no:

Yes I can, if you leave those exception to be handled by the build-in dialog.
Which means that you do not intend to provie any helps or options to the user, but only want to display the message and leave it to the user.

No,
because IMHO you still want to handle it in OnException or similar, and it would therefore be easy to write your own MessageDlg

leaving it to the build-in means you assume it is *impossible* that any other exception can ever occur in your app, and also end up with the same dialog => because if that happens, the user of your application has no way to tell, which of the exceptions are "ok" ; and which indicate that the app just had an internal crash and will now be unstable and data may be lost

In other words: I believe the build-in dialog should feature the text: " The application has just crashed. You may press continue and try to save any data before you quit the application."

Best Regards
Martin

Well, that's what I did of course :-)

Michael.

Hello:

A little off-topic and probably just a stupid idea.

I have wondered many times why there are two different sentences to handle an exception and to clean objects etc. I have missed many times in database work.

I mean:

try
  try
   ......
  except
   <handle>
  end;
finally
  <clean>
end;

It would cleaner if it could be written:

try
   ......
except
  <handle>
finally
  <clean>
end;

I suppose there is a misconception in my idea and it is deadly stupid, because Borland must have had good reasons to design it with two separated blocks, but I can't guess why.

Santiago A.

svaa wrote

A little off-topic and probably just a stupid idea.

Not a stupid idea. It is what the Python grammar permits for exception handling.

It seems to be a limitation of the Object Pascal grammar -- and a wholly unnecessary introducing such a change to Object Pascal would require a compiler change, it is probably better to discuss it in the development mailing list, rather than the Lazarus list.

There was such a discussion in a Delphi group, some time ago. I don't remember the arguments, but finally the consens was *not* to combine except and finally into one try block.

DoDi

Why can't we (FPC) support all of it? I have absolutely no idea what the implications would be...

You could have it only available with certain compiler directives, defaulting to not supporting it?

This thread would be better located at one of the Free Pascal mailling lists.

Felipe Monteiro de Carvalho escribi?:

This thread would be better located at one of the Free Pascal mailling lists.

What is the proper Free Pascal mailling list? where can I subscribe to post a message?

Santiago A.

Here:

http://www.freepascal.org/maillist.var