situations.


Noted your self-correction point, that's ok.

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