I’m in a medical office this morning trying to schedule an appointment. The receptionist is clicking away with the computer mouse, and then she says, to no one in particular:
"Cannot perform this operation on a closed dataset?!?" What’s that mean?
I replied, "It means that someone has a bug in their Delphi application."
{ 4 } Comments
Exceptions are meant to be unexpected errors. All expected errors should be handled nicely. A good error message tells, that there is problem (this message does), it gives a hint about what the problem is so that tech support has an idea (this message does, although not too well), and it gives a hint to the user on how to proceed. This message does not give a hint on how to proceed, but frankly, how many error messages do that?
I think it is wrong to blame the default exception handler for this one. The correct one to blame is the programming team, who did not employ good quality control, and didn’t put mechanisms into place to handle states in good ways.
Lars, let me clarify for you — something didn’t get through.
First, let’s be clear about when exceptions are appropriate. Exceptions are for when the contract of a method is violated, whether it’s "expected" or not. The oft-repeated notion that exceptions should be "exceptional" is circular, not based on a solid theoretical model of SEH, and results in unclear thinking. Without any additional information, I would guess that in this case it’s likely that the exception was thrown appropriately from within the VCL due to a bug in the application code.
Now, did I just blame the default exception handler? Read the post a bit more closely and you’ll see that I did not. I said, "someone has a bug in their Delphi application," so it should be pretty clear that, like you, I think the programmer was likely at fault for the specific error in question. Of the default handler, I said that it was a "mixed blessing," not a curse.
So why bring up the default handler at all? Well, that’s the real point of the post.
Consider an environment which behaves differently, like WinForms. A similar (and similarly unhandled) exception thrown in a WinForms app would result in the application dying with a stack dump. The user would have to restart, which, as it happens, was exactly what this user did anyway with the VCL app she was using.
So in this specific case, which is better?
o User gets cryptic error, quits app, restart.
o App dies with cryptic error, user restarts
The former "looks" less serious and the user might be able to save unsaved work before quitting, but may leave the app in an unstable state. The user could potentially continue working and corrupt their data.
The latter is one less step for the user, and may send a stronger signal to testers/users that there is a bug which needs to be fixed, but the user might lose unsaved data right away.
Obviously the only good solution to this specific problem is to fix the bug. But to the general question of is it better for the app to die immediately or limp along injured for a while, this example doesn’t offer a clear winner.
As an added complication, the VCL frequently throws or requires (non-"silent") exceptions in times which are not appropriate by nearly anyone’s definition of what is appropriate, such as in a TField.OnValidate handler. In the case of OnValidate, the exceptions are both "expected" and within the contract of the event.
What it does tell us is that the default exception handler might save a bit of work for trivial applications (it will display the correct error message for a required field left empty, for example), but that much more work is required for non-trivial apps.
IMO the default exception handler is basically _the_ place to put code that can process a genuinely unexpected exception and display a nice message like "The following unexpected error occured Try to save your work and then exit the application/call support/phone your mother" etc).
It allow the centralised use of MadExcept and any other exception reporting mechanism.
But, it’s up to the programmer to:
a) code defensively (I know that exceptions theoretically negate the need for this, but I still think it’s important as it concentrates the mind and makes for more robust code)
b) catch all potential (and deliberate) exceptions in try…except blocks within their procedures so exceptions don’t "leak" to the default exception handler.
Just my 2c…
I love the "Access Violation" messages. Customers call us and blame Microsoft Access for the error, and asks if we could perhaps find a workaround for this in our application
On a more serious note, we trap exceptions in the Application.OnException, and wrap the message in a more friendly dialog. It’s especially handy when you create applications for a non-english market for which there is no translated version of Delphi (like norwegian).
Post a Comment