Re: Exception handling philosophy
- From: "Roger Lascelles" <rogerlasAToptusnet.com.au>
- Date: Sun, 11 Sep 2005 12:04:59 +1000
"Richard Grossman" <rgrossmanDELETE-THIS-PART@xxxxxxxxxxx> wrote in message
news:43236dab$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> I've been trying madExcept. The reports and dialogs displayed could be
> very helpful and look very professional.
>
> However:
>
> I'm running into a problem with the theoretical side.
>
> 1 I have deliberately raised exceptions - these never need a bug report
> or any additional handling since it's all coded in.
>
> 2 There are exceptions that are explicitly handled, such as during
> opening and saving files, and don't need any additonal handling since
> they represent a local issue and not a bug.
>
> Therefore, I can't have all exceptions treated as bugs and handled in a
> bug-reporting system. And it's not really based on a particular
> exception type, it's really code-location based.
I think you need to add a little more detail - it is not clear to me exactly
what is worrying you?
MadExcept provides a final handler for any uncaught exception. The idea is
that by the time an exception gets to MadExcept, it is an unforseen
situation - and time to close your program. This is different to the
standard Delphi application exception which simply shows the message - and
goes back to waiting for the next Windows message telling of a button click
etc.
The idea of making all uncaught exceptions "fatal" forces you to face some
tricky issues, because you have to catch all the exceptions which you
"expect". The only way to know which exception types are raised by the VCL
and RTL is to view the source provided by Borland. Presumably the
exceptions which Delphi propagates through from Windows can be permitted to
be fatal.
For a serious program which handles important data, the fatal uncaught
exception approach can protect data, because the exception means something
has happened which I did not forsee - possibly something like inability to
allocate memory, hard disk trouble, Windows going wobbly, a bad pointer - or
more likely a fault in my program design - and can involve an error
condition raised by the VCL or runtime library (RTL) which I did not realise
was possible. I you are going to terminate on uncaught exceptions, you must
commit to rigorous testing and quick follow up on every user error report -
or people will get angry with your program which keeps shutting down! I
have a large product at hundreds of sites which uses this approach and it
has been possible to keep customers happy. The error reports which come in
are useful and contain rich information which users could not easily
communicate themselves.
The Delphi style of error handling is rightly criticised :
http://www.joelonsoftware.com/items/2003/10/13.html
http://blogs.msdn.com/oldnewthing/archive/2004/04/22.aspx
Where Delphi exceptions shine is for decent quality but not perfect
software. Most of my software is like that - built for heavy use, but with
limited programmer time. I leave the standard Delphi exception handling in
place and catch the exceptions I am interested in. All the other exceptions
go through and get displayed - everything from a TFileStream error when
opening a file to a Windows API function refusing to do a simple operation.
Thanks to try..finally, I don't have resource leaks. If an exception
message gets through and actually warns of a situation which is fatal, the
user can soldier on - but Windows will eventually kill the program or the
user will give up - not ideal, but rare anyway. It seems that the Delphi
IDE uses this error handling approach.
The standard Delphi exception system lets you handle all the errors in you
own classes and libraries by simply raising an exception when something goes
wrong. This helps with code reuse and keeps "big picture" issues out of
low level code.
Delphi error handling is certainly not right for controlling a space
vehicle - but perfect for use in analysing space data sent back !
I don't think you can combine MadExcept with the standard casual Delphi
exception approach. You have got to program to a higher standard, do more
testing and hunt down every bug. For in-house software, probably not worth
the cost.
Roger Lascelles
.
- References:
- Exception handling philosophy
- From: Richard Grossman
- Exception handling philosophy
- Prev by Date: Re: Fastcode Donations - Help
- Next by Date: Re: Exception handling philosophy
- Previous by thread: Re: Exception handling philosophy
- Next by thread: Re: Exception handling philosophy
- Index(es):
Relevant Pages
|
