Question: I was writing code with exception handling the other day, and I had a few questions about exceptions, their guarantees and throwables.

Basically, say you have:

```
class X {
string m_str;
X() : m_str("foo")//what if this throws?
{
    ifstream b("a.in")//what if this throws?
}

```

And after running through all the articles I could find, I still have no idea what is the clean way to handle this.

Say I have a code like:

```
{
    ...
    X myInstanceOfClassX;
    ...
}

```

Should I wrap the code in `catch(exception &)`? And if I do that, does `string` and `ifstream` guarantee a strong guarantee, that no resources are leaked and nothing has been left half opened?

Also, if my class throws `myexception`, that is derived from exception, `catch(exception &)` seems to let it through. So that leaves me with `catch(...)` which IIRC catches access violation?.? Is there another way?

Then there was a piece of information somewhere that any exception thrown in subconstructors of object constructor shouldn't be caught, and constructor should throw in case any of the member objects throw.

And what if the code above would have been called not from constructor, but from regular a function `void foo()`, which exceptions should I catch? outofmemory\_something, filenotfound\_something? Where can I find the definitions of what STL objects can throw? Are they implementation specific?

Where is the authoritative source where I could clear all my doubts and questions on this topic?

So far, it seems that handling exceptions is like dancing in a big pile of gooo. Error codes seem A LOT simpler and safer...

Answer: 
Every function has a precondition and a postcondition. The correct time to throw an exception is when the postconditions cannot be satisfied. There is no other correct time.

There are two special cases.

* *The postcondition for a constructor is the existence of a valid object*, therefore throwing is the ***only*** reasonable way to report an error. If you have something like a `Foo::is_ok()` test then what you have is a valid object which represents an invalid state.
* *The postcondition for a destructor is the nonexistence of an object*, therefore throwing is ***never*** a reasonable way to report an error. If you have something tricky to do at the end of an object's life, do it as a separate `Foo::commit()` member function call.

Beyond this you have options, and it's a matter of taste.

For example

* `std::vector::operator[]` does not check preconditions and is `noexcept(true)`, but
* `std::vector::at()` does check, and throws.

The choice is whether or not you assume your preconditions are valid. In the first case you are using design-by-contract. In the second case, *given* that you have detected that they are not, you *know* the postconditions *cannot* be valid and therefore *should* throw; in the first case you *assume* they are and, *given* that, the postconditions *must* be valid and therefore you *never* need to.

GOTW covers a lot of the dark corners of exceptions and demonstrates nicely [why things are what they are](http://www.gotw.ca/gotw/066.htm).
The only authoritative reference on how the standard library works, including under which conditions it is allowed to throw which exception types, is the C++ Language Standard. Years ago it was available in electronic form for a reasonable price, but unfortunately this doesn't appear to be the case anymore. You might consider searching the [Standard Committee site](http://www.open-std.org/jtc1/sc22/wg21/) for drafts, but there will obviously be differences with the published standard.

Note also that a new edition of the standard has just been publish and it will take some time before vendors implement the new features with reasonable completeness.