"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.