line 646: Normally it's undefined behavior to dereference an iterator like this. I would prefer an assert to throwing an exception.
The point is that these locations are valid positions just you can't call operator*.
I think it is better behavior because it is quite easy to make a mistake with this.
(From my experience with this)
Of course, it's a good thing to detect the error. The thing is that an exception means that you unwind the stack, possibly handling the exception at a higher level. That's normally not the correct response for a programming error.
It is similar to std::vector's at()...
Maybe, in any case I had found exception helpful, especially in situation when you don't a error in some part to shutdown entire process.
Defensive but forgiving programming.
Definitely a no-no. Dereferencing an invalid iterator is a programming error, not an exceptional situation.
The thing to use is an assertion.
When your code is statically wrong, the compiler refuses to generate a binary. Likewise, when your code is dynamically wrong, it just terminates.
Fix your code such that such situations may *never* happen. An exception is something that *could* happen, even in bug-free software, like a failure to perform an operation due to lack of the necessary resources.
I'm sorry but as far as I remember nobody deprecated std::logic_error (and std::out_of_range derived from it). Small point, when you program some mission critical systems and services you don't want the process to go down for something that maybe only a single response can go down that way. This is very important for some mission critical code (and I had written such code not once). In any case, this concept is part of C++03 and C++0x and can be seen via std::logical_error that allows to catch programmers errors. Artyom _______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost