🚀 go-pugleaf

jss@lucid.com (Jerry Schwarz) writes:
: 
: The later included the only people (a medical software group at HP)
: with experience using exceptions in C++. I asked them whether "out
: of memory" had to always be included on their lists and they said
: they didn't treat "out of memory" as an exception.

I think the issue is broader than that.  It is likely (IMO) that certain
"system failure" exceptions will occur at unexpected times.  Examples
include "out of memory", "invalid pointer dereference", "divide by zero",
"OODB deadlock" etc.

For a program where it is unacceptable to terminate when this happens,
the ARM provides the opportunity to replace the predefined unexpected()
function with a custom one.  Suppose you wish to nevertheless
propagate these exceptions to a CATCH block, no matter what
the exception specifications say.  Is it OK for unexpected() to
simply rethrow the exception?

If this is _not_ allowed, then I'm afraid many functions (for example
in life-critical systems) _must_ specify every "system failure" like
exception, causing an avalanche of these throughout the entire program.
Commercial libraries will need these too (to enable the broadest usage).

: At the moment X3J16 is considering the implications of exceptions
: for stream classes.  Some think that streams should only
: be able to throw a particular kind of exception (tentatively
: named ios::failure). Others (including myself) feel that a stream
: should be able to throw an arbitrary exception. Remember, users
: can define their own kinds of streambufs, so X3J16 can't know in advance
: what kinds of conditions they might want to report.

But they may inherit their exception types from ios::failure, no?
Does bring more structure to stream error handling, IMHO.
Derived streambufs will be required to catch and translate non-ios
exceptions.

: [...]This leads me to the conclusion that the iostream library
: should not use failure clauses.

But this means every function using streams must catch all exceptions,
or refrain from using exception clauses, and the functions calling those
functions, and so on.  We end up with programs with either a lot
CATCH blocks, or very few failure clauses.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------