Re: Evaluating Exceptions, Try Except and Try Finally

From: Bruce Roberts (ber_at_bounceitattcanada.xnet)
Date: 04/08/04 

Date: Thu, 8 Apr 2004 10:55:40 -0400

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:c53at9$vt4$1@news4.tilbu1.nb.home.nl...

> So now I can go change all my code everywhere... so it says:
>
> try
>
> Connection.Open;
>
> finally
>
> Connection.Close;
>
> end;

Then you will only prove your stupidity. As others have mentioned several
times the above structure is NOT the way to code things. When using try
finally to protect resources the format is

allocate the resource
try
    work with the resource
finally
    release the resource
    end

If you code things correctly, i.e. the way the designers of the language
intended, then you are going to find much less to complain about. An
interesting side effect is that your programs are going to start operating
correctly.

I'd advise you to stop trying to force Delphi into some form that you
consider correct. If you start to code the way the language designers
intended, you are going to find that your job becomes much easier and your
code becomes much more robust.

I and others have repeatedly stated the general rule of thumb when it comes
to using try except. You seem totally unwilling to accept that the approach
might work. Its pointless to argue details when you have demonstrated a
total lack of and unwillingness to gain understanding of the general
principal.

Try finally bears no relation to try except, other than their syntactic
similarity. They do not go hand-in-hand. In fact thinking of them together
will only lead one down the wrong path. Try finally should be used to
protect resources. One should use it whenever one allocates a resource. In
my experience this is fairly often. Try except, OTH, is designed to handle
exceptions. It should only be used under very specific circumstances. In my
experience try except appears rarely in well written applications.

Consider your database example. One presumes that somewhere in your
application there is code that needs an open database. If the app has to
have this database open in order to function at all then one will code the
exception handling differently than if the db open is something optional. In
both cases the code that actually opens the db shouldn't be the one making
this determination, it really should be done by the code that asks for the
open.

> The only big drawback is that... the exception will happen after the
> connection is closed.. that's weird !

Actually this can be a huge advantage. Its one of the really neat things
about the exception model. One is not forced to stop everything to deal with
an exception. Instead the code notes the exception, and the fact that it has
to be dealt with, then it can proceed to clean up the mess before having to
advise the user that something is not right.

Your preference to use pass/fail tests demonstrates to me that you are
either a coding masochist or that you have not had to write a production
application of any real size.

Relevant Pages