Article

From:
To:
Kristofer Skaug
Subject:
Re: Exceptions vs Error codes
Newsgroup:
borland.public.delphi.objectpascal

Re: Exceptions vs Error codes

In article <3b7f9bce_1@dnews>
	"Kristofer Skaug" <✉skaug.demon.nl> wrote:

> "Barry Kelly" <✉eircom.net> wrote in message
> news:✉4ax.com...

> > Woah! Exceptions are valuable:
> >
> > 1) They force error-handling; that is, they prevent code from
> > blundering on regardless of errors. This, in my book, is a 
> > lot worse than simply crashing out.
> 
> 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?

And you consider this an advantage?
> > You seem to believe that the risk of letting a program continue in the
> > face errors to be a virtue, if you are opposed to exceptions like this!
> 
> 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.

> This is what fault tolerance is all
> about.

Hm. Not in my book.

> In case of a real error (exposed fault, leading to true failure of a
> module), I am *not* saying one should go on as if nothing happened, but
> that one shall have the option of continuing with a graceful shutdown
> and/or restart in a controlled manner, not just to get blown out of the
> water. A failure in a software module *can* be survived if the module can
> be verified as still healthy, or by restarting the concerned module.

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.

> > I feel like SHOUTING! That isn't what exceptions are about. Look:
> >
> >   a := TA.Create;
> >   try
> >     a.Stuff;
> >   finally
> >     a.Free;
> >   end;
> >
> > Guess what! The finally part has access to local state!
> 
> I didn't (mean to?) say that this was not feasible. What I am saying is
> that an error during "a.Stuff" transactions usually has no business being
> resolved anywhere beyond the local context, except as a "last line of
> defense".

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

> Often I hear exceptions being touted exactly for their
> wonderful capability to bubble up to the application surface, *all by
> themselves*!

This is because this is desirable behaviour for the transaction-like
nature of most applications. They try something, it doesn't work out, so
they roll back. It isn't often that they try to recover, because the
fault that caused them to fail is either:

1) Faulty input - alert the user.
2) Faulty programming - a bug; fixing the bug should be more important    than a band-aid.
If you wander parallel to this large highway someplace, then it might not be the very best for you.
I still reckon it's better than error codes.
> This is the sort of exception behaviour I *don't* particularly like.
> If every error situation you need to handle specifically (and locally)
> requires its own try-finally clause, now that's the point where I say:
> it's easier and cleaner to go by error codes. But that's just me I guess.

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.
> > I disagree; certainly, I don't know your exact domain, but fault
> > tolerance isn't trivial. However, I don't think exceptions make it
> > harder; in fact, I think they are better than other mechanisms, if only
> > because they hit you on the nose if you try and ignore an error
> > condition.
> 
> I don't like being hit on the nose. I'd rather have a quality oriented
> tool tell me if my source code is vulnerable to unhandled error
> conditions in certain spots. I never *try* to ignore error conditions
> unless I'm sure I don't care about the outcome. In which case the further
> progress of my application truly doesn't depend on it. (for example, say
> I send something to a network printer. Due to e.g. network problems,
> printing fails. My application's state is independent of success or
> failure of the printing operation, so I don't care about the return code
> or exception thus resulting. But an unhandled exception could kill my
> application, even though I didn't care about it.

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!

***
I appreciate this debate; it's getting the ideas more solid in my head.
-- Barry
--   If you're not part of the solution, you're part of the precipitate. Team JEDI: http://www.delphi-jedi.org NNQ - Quoting Style in Newsgroup Postings   http://web.infoave.net/~dcalhoun/nnq/nquote.html
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Tue, 07 Feb 2023 04:48:59 UTC
Copyright © 2009-2023
HREF Tools Corp.