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: 
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.
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.