Article

From:
To:
Barry Kelly
Subject:
Re: Exceptions vs Error codes
Newsgroup:
borland.public.delphi.objectpascal

Re: Exceptions vs Error codes


"Barry Kelly" <‚úČeircom.net> wrote in message
news:‚úČ4ax.com...
> > No they don't force error handling, but they punish you mercilessly if
> > there's a hole in your code.
>
> So you wouldn't be punished if there was a hole in your code and you
> were using error codes?

Generally yes, but not necessarily in such a nuclear bombing manner.

> > It *is* a virtue to survive errors.
>
> If they weren't exceptions, and were error codes instead, and you didn't
> treat them as seriously as you must exceptions, then you wouldn't be
> surviving errors - you'd be ignoring them.

there are lots of 'ifs' in that statement.

> > This is what fault tolerance is all about
>
> Hm. Not in my book.

This is abundantly clear <g>

> I don't see how it is any different between error codes and exceptions;
> exceptions just force you to deal with errors, rather than ignoring
> them.

ok, looks like we're back to square 1. Maybe one day I'll come up with a
more convincing way to put my argument.
Stay tuned...! <g>

> Then try to deal with it where it failed! Transactions can be nested; if
> you feel you can "TryHarder", then TryHarder; but if not, then re-raise
> the exception. (See my other post.)

see my comments there.

>
> 1) Faulty input - alert the user.
>

ok, but I don't see input errors as faults; failure *due to* input error
is a fault (a decent program should be immune to input errors, i.e. not
fall over because of it).

> 2) Faulty programming - a bug; fixing the bug should be more important
>    than a band-aid.

yes, you want to fix the bug.
but it is too late and may have caused irreparable damage when it happens
the first time.
especially if the means of exposing/publicising the error participates in
aggravating the consequences.

> But what about when you finally decide you can't deal with this problem,
> and you must pass it up to your most senior transaction, and say "I
> can't do this Boss". He might have to say the same to his boss too; this
> is what exceptions are for. They pass the same / extended letter of
> failure around so that if the whole process ultimately fails, because
> the workarounds weren't clever enough, there'll be some documentation
> that can be placed in the lap of some human somewhere sometime.
>
> Error codes can make this very messy; other approaches pass logging
> objects around. I think exceptions are neater than either.

No it's not really that messy. For example, the way I ususally do this
is:

function BigBoss():TErrorInfo; var MidError:TErrorInfo; begin    MidError:=MiddleManager();    Result:=f(MidError); end;
function MiddleManager():TErrorInfo; var EngError:TErrorInfo; begin    EngError:=JuniorEngineer();    Result:=f(EngError); end;
function JuniorEngineer():TErrorInfo; var LowError:TErrorInfo; begin    try       LowError:= SomelowlevelAPI;    except       LowError:=ERR_API_EXCEPTION;    end;    Result:=f(LowError); end;
Furthermore, at each level the function can signal error info to the user interface if deemed necessary. Also, the error information is abstracted to an appropriate level in each step; for example, BigBoss() cannot use any information about ERR_API_EXCEPTION, it has no idea what that means. The only language BigBoss understands is MiddleManager saying "We have technical difficulties, and have taken steps to fix them". BigBoss on his side concludes that "we'll have a 2 week project slip and $180,000 lost profit". Of course, all JuniorEngineer() is able to say is "SomeLowLevelAPI failed with error code -18907.", a message which is of absolutely no use to BigBoss. So that's why I feel also, that just passing some low level exception on to BigBoss has little actual value.
> If you're application needs to print, and you don't care whether it
> prints or not, then the application shouldn't be designed in such a way
> as to make the stability of the system state dependant on whether or not
> an exception is raised!

True, there should be an exception handler to protect this.
The point was, that if the TForm.Print method had simply returned an
error code I could've skipped that part and just left it as "I've done
what I can, and I'm not going to try harder; if it fails, it's not my
fault anyway and the user has to figure it out.". (e.g. printer not
installed, blablabla).  It is an error from a printing perspective, but
due to the spec of my application ("send job to printer", not "guarantee
it is printed") it is not a fault, so an exception is inappropriate for
me at that point.

> I appreciate this debate; it's getting the ideas more solid in my head.
>

it's a challenge for me too, to have to explain the rationale behind the
way I do error-handling.
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Tue, 07 Feb 2023 05:57:03 UTC
Copyright © 2009-2023
HREF Tools Corp.