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).
AFAIK whether or not (and more importantly, which) exceptions are thrown is mostly left to the implementation. I don't see any point in attempting to catch those - I mean, what are you gonna do if this fails? Is there any reasonable way to recover from an exception being thrown there?

Keep in mind that no exception is thrown if, for example, a file can't be opened - that would simply lead to the stream being set to a fail state.