On 2013-08-23 09:50, Atgeirr Rasmussen wrote:
> I tried to be rigorous about always using very specific exception
> classes, creating a large hierarchy of such. However, I gradually
> stopped doing this, as I saw very little benefit
I've had a similar experience. In the beginning I used to create an
exception class for each possible failure point, to be thrown from
there. Later, I have reverted to creating one exception class per
library (or major functionality) with a code (errno if you want)
describing exactly where the failure happened.
The reason for this is that many/most errors happens because of external
reasons (e.g. non-conforming grid, file does not exist), and that the
site of the catch is seldom able to do anything more sensible than to
log a message anyhow, something like
catch (std::exception& ex) {
std::cerr << "Error: " << ex.what();
}
However, a key point here is that all such exceptions should inherit
(virtually) from std::exception.
> report errors with the THROW(something) macro from ErrorMacros.hpp.
> This just sends file and line number plus the 'something' part to
> std::cerr, and throws a pure, unadorned std::exception.
I don't think it is particularily nice to assume that cerr is available
in a library, so I support the notion that this information should
rather be put in the exception and printed as part of the log.
On 2013-08-23 12:06, Andreas Lauser wrote:
> punching 'catch throw' into GDB makes it break whenever an
> exception is thrown. this is a thing that is very hard to do for the
> traditional way.
> ...
> eWoms catches 'NumericalException' and tries again with a smaller
> timestep. As you can imagine, is a relatively common case.
I think this is a bit contradictory, as it will be a nuisance to have
the debugger break whenever there is such a condition, and I have a
suspicion that this is the crux of the tension between the two camps in
exception usage.
The core of the problem is that exception handling is in C++ by far the
easiest way to implement Maybe[+] *and* at the same time logging
failures, without getting bogged down in endless reams of boilerplate.
Maybe it is so that the Newton solver should throw an exception *not*
rooted in a common hierarchy if it fails to converge, that this should
be expected to be handled separately by the calling code, and that you
want to abort() if this exception leaks out of the library as a whole?
--
Roland.
[+] Sorry for namedropping, but if you want to know what I mean by this,
then search for "Maybe monad".
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
