throwable .vs. non throwable?

[James Kanze]

[ ... ]

unexpected() aborts, period. By default at least.

I suppose that depends on what you mean by default -- if the exception
specification in question includes bad_exception, the stock version
(i.e. not as a result of set_unexpected) can/will throw objects of type
bad_exception. Of course, as long as you only write empty exception
specifications, that can't happen...

Are you sure? I'm looking at the lastest draft of the standard
(but I don't think anything has changed here), and for
unexpected_handler, it says: "Default behavior: The
implementation's default unexpected_handler calls terminate()."
It's only if a user defined unexpected_handler throws an
exception that bad_exception comes into play.

Quite true.

At least you hope so.

I, for one, find the information supplied by the assert useful.

It can be useful. It's very useful in my unit tests, for
example. If you're implementation of std::vector<>:perator[]
asserts, however, I'm not sure that the message will be very
useful. My experience is that in large applications, the assert
is usually in a function which has been called with the wrong
arguments, and you still have to determine who called it.

Yes,
there are times it can be/is discarded, but at least to me there's a big
difference between deciding that it's reasonable to discard information
for your specific application(s), and deciding at the language level
that all such information must be discarded for all possible
applications.

At least on my systems, calling unexpected doesn't discard any
information. It just doesn't output anything on standard error.
The stack has not been unwound, and the critial information is
there in the core dump (at least most of it, most of the time).

Probably, an assert instead of the throw would be even more
useful. But if the code is wrong, the core dump from unexpected
is better than nothing.

[ ... ]

An exception specification without bad_exception will not cause
bad_exception to be raised. Since the only really useful
exception specification is an empty one, which doesn't allow
bad_exception, you should never see this exception.

I can't agree -- if you're seeing an exception raised that shouldn't be,
I think (a modified version of) bad_exception would be a useful way to
help diagnose the problem.

How? If you catch it, the stack has been unwound, so you don't
know where you were. And you've probably violated some pretty
important invariants. If you don't catch it, then you get a
core dump. In which the stack may have been unwound (although
as a QoI issue, I would expect it not to have been).

That's with the current situation, of course. If it were
somehow possible to obtain information about the original
exception, it might be more useful. But I still prefer a core
dump.

 

[Jerry Coffin]

On Jul 27, 4:06 am, Jerry Coffin <[email protected]> wrote:

[ ... ]

Are you sure? I'm looking at the lastest draft of the standard
(but I don't think anything has changed here), and for
unexpected_handler, it says: "Default behavior: The
implementation's default unexpected_handler calls terminate()."
It's only if a user defined unexpected_handler throws an
exception that bad_exception comes into play.

$15.5.2/2 [except.unexpected]:

If it throws or rethrows an exception that the exception-
specification does not allow then the following happens:
If the exception-pecification does not include the class
std::bad_exception (18.6.2.1) then the function
terminate() is called, otherwise the thrown exception is
replaced by an implementation-defined object of the type
std::bad_exception and the search for another handler
will continue at the call of the function whose
exception-specification was violated.

As of N2315, dated 2007-06-25, this remains unchanged.

[ ... ]

At least on my systems, calling unexpected doesn't discard any
information. It just doesn't output anything on standard error.
The stack has not been unwound, and the critial information is
there in the core dump (at least most of it, most of the time).

My point is that by the time unexpected() is called, the original
exception object has disappeared; that's what I'm talking about as
useful information having been discarded -- at least assuming you design
your exception classes well, it's like to contain much more specific
information about the exact problem than a core dump.

Based on Howard's post, however, it appears that in the next version of
the standard, that exception object will beceome available. As such,
this entire problem is (largely) cured, at least as well as writing the
standard can make it so -- now it's just up to the vendors to implement
the new behavior.

Probably, an assert instead of the throw would be even more
useful. But if the code is wrong, the core dump from unexpected
is better than nothing.

Yes, it's better than nothing -- but I think access to the original
exception object is frequently going to be a lot better still.

[ ... ]

That's with the current situation, of course. If it were
somehow possible to obtain information about the original
exception, it might be more useful. But I still prefer a core
dump.

Information about the original exception doesn't rule out a core dump
though -- rather the contrary, if the program aborts, I'd expect a core
dump as well. Sometimes the core dump might be more useful -- but at
least at that point I have the option of looking at the original
exception object, and chances are pretty good that I can quickly
determine whether it's useful, and proceed to using the core dump if
(and only if) it's not.