QuoteOriginally posted by: rmaxWe seem to be having some design decisions around the error handling be owned by the caller, and not the recipient. Is this a decision?I think there are thousands of viewpoints on this subject; the following are strategies:QuoteThere are several levels of exception safety:1. Failure transparency, also known as the no throw guarantee: Operations are guaranteed to succeed and satisfy all requirements even in presence of exceptional situations. If an exception occurs, it will not throw the exception further up. (Best level of exception safety.) 2. Commit or rollback semantics, also known as strong exception safety or no-change guarantee: Operations can fail, but failed operations are guaranteed to have no side effects so all data retain original values.[2] 3. Basic exception safety: Partial execution of failed operations can cause side effects, but invariants on the state are preserved. Any stored data will contain valid values even, if data has different values now from before the exception. 4. Minimal exception safety also known as no-leak guarantee: Partial execution of failed operations may store invalid data, but will not cause a crash, and no resources get leaked. 5. No exception safety: No guarantees are made (Worst level of exception safety). And do we use try-catch blocks or ERRNO stuff? And exceptions are not the same as failures, according to Bertrand Meyer.

QuoteOriginally posted by: outrunQuoteOriginally posted by: rmaxWe seem to be having some design decisions around the error handling be owned by the caller, and not the recipient. Is this a decision?I would prefer a mechanism that does error handling by default, but that can be completely eliminated by the caller compile time.E.g. we can use something like this?// default, checkdouble my_sqrt(double x){paramchecker::check(x);return sqrt(x);}// alternative user definable checkertemplate <class T>double my_sqrt(double x, T paramchecker){paramchecker::check(x);return sqrt(x);}What happens if I call my_sqrt() in a loop with data I know is correct? It will be inefficient. BTW my_sqrt() does 2 things. We can check constraints at a higher level once.

Boost Math Toolkit might be a good place to see how they have done it. Maybe standardise in STL exception in the beginning.

BTW exception handling is concerned wiith IS09126::Reliability::Recoverability. This sub-characteristic needs to detemined if it is on the critical path in early releases.