Yup, indeed you're going again. But this post has been most useful. Thanks
for taking the time to do it.
I follow all the logic, and agree with all of it, up to the last lines.
> rather than an exception, since exceptions are really contrary to the
> philosophy of error containment.
If I think of my block of code being a function, then I would describe the
calling function as the 'big boss' in your terminology. If, for example, I
write a routine to update the time stamp on all the files in a directory,
(touch.exe) I could use an exception to handle. This is an expected
condition that the program can't do anything about, but it shouldn't kick
the problem back to the user.
For me, the benefit of using exceptions, is that I don't have to figure out
what went wrong when updating the time stamp. If the UpdateTimeStamp
routine throws an exception, I can ignore it, and let the program terminate;
or I can catch it, log it and keep going; or I can catch it, change the
read-only attribute, call it again, and then keep going. That's why I've
been leaning towards an 'exceptions for everything' approach.
BTW: Thanks to everyone for contributing to this thread. Even though I know
some of you got kinda' roped in just to edutain me ;-)
-pete
"Kristofer Skaug" <✉skaug.demon.nl> wrote in message
news:3b785da5_1@dnews...
> "Greg Lorriman" <✉bigfoot.com> wrote in message
> news:3b7848f8_1@dnews...
> > I don;t think that I said that exceptions are for unanticipated
> situations.
>
> Noted your self-correction point, that's ok.
>
> > My emphasis is on contracts being broken or, if you like, invalid
> parameters.
>
> It's really a style question. Let me try to describe the fundamental
> philosophical split between active exception usage and exception containment
> strategy as I see it; Beginning with the question: What is the fundamental
> 'mandate' of a program, a function, a procedure or a code block within a
> function/procedure?
>
> 1) In the exception-oriented world, it is to fulfil the nominal path
> ('mission') of a program. All circumstances which hinder this objective are
> regarded as exceptions and are handled (if at all) *outside* the program /
> function / procedure / block (by the caller). This means that by using
> exceptions one is shifting the responsibility to tackle error conditions to
> a higher level in the calling hierarchy. The program (or function within a
> program) (or block within a function) will have failed (exited abnormally),
> and the caller of that block or function or program will be responsible for
> calling the retry, if desired.
>
> In this system, lower level functions or code blocks are intentionally
> unforgiving to any and all errors and anomalies, kicking responsibility for
> recovery up the ladder. It is the 'big boss' at the top (the Application
> exception handler, or in the worst case the program invocator) which decides
> how to proceed from there. Exceptions are ideal vehicles for such a system
> of error passing / handling.
>
> 2) In the exception-denial world (mine, for the time being), the mission of
> a program, a function, a procedure or a code block is to complete the normal
> path of execution /as far as possible, even when faced with anomalous
> conditions/; the primary responsibility for resolving error situations
> (invalid input, failed connections/allocations, timeouts, etc) is /contained
> within the function/ and thus common/anticipated error situations are *kept
> invisible* from the higher levels of the calling hierarchy for as long as
> possible (until the situation is locally deemed unrecoverable or further
> continuation is aborted by user intervention). This means that the program
> or function will be conditioned to complete its mission normally if at all
> possible, and the higher levels of the hierarchy can assume that when or if
> that program or function fails, the situation is truly unrecoverable.
>
> In this system, each function takes maximum responsibility for ensuring the
> success of its mission, refusing to exit abnormally unless facing an
> unrecoverable anomaly (given their local scope and resources). If/when this
> happens, in my code they return an unmistakable error code (if possible)
> rather than an exception, since exceptions are really contrary to the
> philosophy of error containment.
>
> [there, you've got me going again...<g>]
>
> Kristofer
>
>