Re: Evaluating Exceptions, Try Except and Try Finally
From: Rob Kennedy (me3_at_privacy.net)
Date: 04/08/04
- Next message: Skybuck Flying: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Previous message: Daniel O'Connell [C# MVP]: "Re: the garbage collector"
- In reply to: Skybuck Flying: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Next in thread: Martin Strand: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Reply: Martin Strand: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 08 Apr 2004 11:40:56 -0500
Skybuck Flying wrote:
> I am just going to add some more comments here :)
Gee, lucky us.
> 1. Raising Exceptions is not ment as a means of returning success/failure or
> returning error codes.
I beg to differ. I quote the help file:
"An exception is raised when an error or other event interrupts normal
execution of a program."
> 2. Try Except, Try Finally is not a replacement for IF THEN ELSE !
> 3. Software like .NET which returns many exceptions is an indication that
> the software is:
> A. Still new and has many handled situations and therefore an exception
> is raised.
> B. Programmers that did not take or have the time to resolve these
> situations.
Delphi has used exceptions since the beginning. So has C++. So has Java.
If you have a problem with the frequency with which exceptions are
raised in .Net, then go take your complaints to a .Net newsgroup since
they really aren't Delphi-specific. Microsoft has an extensive
collection of newsgroups on its server, msnews.microsoft.com. I'm sure
the people there would be delighted by your wit and charm.
> 4. .NET is still new and badly documented, in many cases it is unknown if
> exceptions are raised, leading to paranoya:
> "I better place try except blocks everywhere, since I dont know what
> will and will not raise exceptions".
No, you should put exception handlers at the places where you are
*expecting* that an exception will occur. If you have no idea whether an
exception will be raised, then you such absolutely *not* use an
exception handler. Since you have no idea what kind of exception will be
raised, it would be impossible for you to write code that reacts to that
exception in a sensible way.
> 5.
> I would advice to use Exceptions only when the programmer really, really
> really does not know how to resolve a situation... or just doesn't have
> the time to resolve.... but the design of the software should be in such a
> way that it returns success/failure and possibly error codes. So that later
> code won't be broken. For .NET it's now too late... if for example
> Connection.Open is now change so it returns boolean values... my try except
> code will be broken and no longer catch errors/failures.
You and your paranoia! You're so concerned about arbitrary changes to
published APIs. The API *won't* change. If it does, you would need to
update your code anyway. Everyone learned that when Windows 95 and the
Win32 API came out. It required lots of changes from the Windows 3.1 way
of doing things. And those changes had nothing to do with exceptions.
The error codes changes. The means of returning error codes changed. The
problems you're describing aren't limited to exception-based code, and
so you aren't providing criticisms of exceptions.
> I will admit that GetLastError.... or GetErrorCode is probably an underused
> api/function. BUT ! Programmers generally do check for return values !
> if function_was_successfull then
> begin
>
> end else
> begin
>
> end;
What, exactly, will you put in that "else" clause? Please give me an
answer for every possible return value from GetLastError. (Mind you,
that's more than four billion possibilities.) I'll permit you to use the
same answer for multiple values, of course, since Error_File_Not_Found
is so similar to Error_Path_Not_Found, but the precise handling of
Error_Is_Joined surely can't be the same as the handling of
Error_SXS_Protection_Public_Key_Too_Short.
> Such functions garantue that something succeeded or failed... it's a
> certainty ! try many instructions except is uncertainty !
The lack of an exception being raised is a guarantee that the function
you called was successful.
> 6.
>
> The flow of code is easy to follow with IF THEN ELSE statements etc. It's
> predicatble and deterministic !
>
> The flow of code is hard to follow with TRY EXCEPT blocks or TRY FINALLY
> blocks or combinations !. It's unpredictable and non-deterministic !
Please don't use terms you don't understand. The code is entirely
predictable. The code is most definitely deterministic.
> 7.
>
> IF THEN ELSE statements allow a programmer to handle situation right there
> and then. Raising Exceptions/Try Except/Try Finally blocks pospone
> the situation which is bad.
If-then-else statements *require* a programmer to handle the situation
right then and there. Raising exceptions *allows* him to handle them
right away, but it also allows him to postpone the handling until
execution reaches a section of code that is equipped to handle it.
> 8.
>
> IF THEN ELSE allow to handle all possible combinations of errors/situations.
> TRY EXCEPT/TRY FINALLY is generally used as lazyness and does not allow to
> handle all situations and therefore leads to much worse applications.
You keep on using "allow" when you really should be saying "require."
The responsibility of handling every possible error is a burden, not a
luxury.
> 9. As stated before TRY EXCEPT/TRY FINALLY costs a lot more time to think it
> through... and requires ofcourse looking up the documentation
> what exceptions are raised if there is documentation at all ! at least
> function booleans/return errors are immediatly visible to the programmer,
> allowing
> him to do basic failure detection and recover from it easily and proceed on
> with the rest of the application.
Here is a real-world example. When the streaming system is loading a
form, there is the possibility that the form resource will contain
entries for properties that do not truly exist in the code. (This
occurs, for example, when a Delphi 7 form accidentally gets linked to a
Delphi 5 program; the DesignSize property doesn't exist in D5. Or when a
component designer changes a component's code and runs a test program,
but neglects to recompile the component package.) When the streamer
encounters an unknown property, it obviously can't set that property --
there is nothing in the class definition to set. The relevant code is in
Classes.pas, TReader.ReadProperty. Currently, it calls the PropertyError
method, which raises an EReadError exception. So tell me please, what
should it do instead?
How would you propose that access violations be implemented, without
exceptions? What is the proper way for a program to check for and handle
access violations, in the absence of exceptions?
-- Rob
- Next message: Skybuck Flying: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Previous message: Daniel O'Connell [C# MVP]: "Re: the garbage collector"
- In reply to: Skybuck Flying: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Next in thread: Martin Strand: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Reply: Martin Strand: "Re: Evaluating Exceptions, Try Except and Try Finally"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
