On 08-10-2013 19:19, Nevin Liber wrote:
On 7 October 2013 21:18, Gavin Lambert
wrote: While it's *possible* that the null came from some global state that will break all future operations, it's more likely that it was some local state within the operation that becomes irrelevant when it starts processing the next operation anyway.
In other words, you are pretending the code knows the root cause of the programming bug it was never supposed to have and can magically recover from it.
(Not sure what this has to do with Boost anymore...)
We are indeed going in circles. I can respect that some people don't want the overhead of the runtime check. I can also respect that people don't want to take down the whole server because of a bug in some subsystem. Software development is such a diverse field, that it's hard to find a one true way of doing things. We just need to find a way to give both camps what they want, since both a valid use-cases. Some libs uses a system of macros to do this, but it's usually to enable/disable all exceptions. Others, like Boost.PtrContainer, allow you to customize the behavior in the type declaration. kind regards -Thorsten