Re: In which case a function / method is guarantee not to throw an
exception ?
* James Kanze:
This is, IMHO, a defect in the standard. Which I don't expect
implementers to take advantage of: the day std::string::size()
throws a double, I'll complain loudly, even if the standard says
that it's conforming. In practice, the only compiler I know
that throws anything that isn't required by the standard is
VC++, and then only if you compile with /EHa rather than /EHs.
About ten+ years ago the Lotus Notes API used to throw integers; I don't know if
it still does but probably it does.
And of course Microsoft's MFC liked to throw pointers to exception objects.
To deal with that kind of mess, at the time I advocated "exception translation"
by using a single catch(...) and a function rethrowing the exception, catching
all the known types, and rethrowing as a std::runtime_error derived exception.
My colleagues thought this was pretty stupid because (1) it was too darn clever
(never mind the paradoxical nature of that argument, "clever" in software =
bad), and (2) MSVC 6.0 had a bug where it didn't properly call destructors when
exceptions were involved, I don't recall the details exactly but it was bad.
Perhaps today compiler conformance & programmer education has advanced to a
point where the exception translation scheme is practical for real-world code?
Perhaps it would be nice with some "standard" support for such translation --
e.g. in the Boost library? Of course, keeping the usage simple (which is the
whole point of the scheme) might be difficult with Boost...
Cheers,
- Alf