Dear OPM-community, I think we need to discuss exception throwing policy a little. This is in part prompted by Andreas' recent PR introducing an exception hierarchy.
First a little personal history. In the early days of standard C++, 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, apart from some exceptional (pun aside, meaning very rarely) situations. Usually, if you would need a varied set of exception classes to be able to report an error correctly the errors are not really exceptional, and other handling strategies are more appropriate (for example, a Newton solver not converging is not an exceptional thing). So over time I gravitated towards the approach followed now in most of the software I have made -- 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. It could be argued that this is somewhat extreme in its lack of information being transmitted with the exception, but my reasoning is as follows: most of the time, the context of the exception is important for debugging, and this cannot be carried by the exception. That is why the macro prints file and line number. On the other hand, the receiving end is rarely implemented (other than, perhaps at a very high level), and would not be able to use this information anyway. Introducing a new exception hierarchy is of dubious value. I think that once you has digested the appropriate usage of the standard range_error vs. out_of_range_error vs. invalid_argument vs. length_error and so on (quick quiz: what is appropriate for an index check in an array), you will not feel the need to complicate any further. If one feels the need for specialty exceptions that is fine, but they should be defined close to where they are used and inherit logic_error or runtime_error. I have to admit that I do not know what is considered to be best practice on this issue these days, so I welcome other people's views. Finally, I'll state the obvious that we do not need to discuss. Yes, we allow throwing exceptions. Yes, all code should satisfy the basic exception safety guarantee (and all developers are assumed to understand what that means). No, we do not require the strong gurarantee (but perhaps we should). Atgeirr Flø Rasmussen _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
