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