Error handling: distinguishing between 'fatal' errors and 'unexpected input' errors

I've been working on a program that reads in an XML file, and if ifstream is unable to open the file, it will throw std::ifstream::failure. This exception is thrown whenever std::ifstream::failbit is set or std::ifstream::badbit is set, and they are (at least in my opinion) the type of errors that warrant exception handling.

After I open the file, I use RapidXML to create the DOM object, and its parse function will throw rapidxml::parse_error if it fails. This is the type of situation where the error isn't really fatal--it's just bad input. At any rate, I think it's still fair for rapidxml to throw an exception when it fails to parse the xml file, but even if I didn't think so, it doesn't really matter, because I don't have too many options. I could turn off exceptions in RapidXML, but then I'd still have to handle these exceptional cases manually, and it's just far easier to handle them via the exception mechanism. However, this is definitely a murky area; the justification f开发者_C百科or rapidxml::parse to throw exceptions isn't as clear-cut as it is for ifstream.

The final case is when I'm parsing the DOM and come across an unexpected or unanticipated node. Clearly, the program can continue executing in spite of unexpected input, but I wouldn't want it to. I could conceivably throw an exception here, but I'm not sure if that makes much sense.

So, I'm asking for a little advice: what are some best practices for exception handling? I try to use the RAII idiom in the class that parses files by doing all of this in the constructor. I use a boost::shared_ptr to instantiate the file parsing class, so if the constructor throws, boost::shared_ptr will rethrow std::bad_alloc after delete'ing the file parsing class.

I can make an argument for having this occur when the XML file doesn't conform to what this class expects, and I suppose it would make sense to throw an exception when presented with unanticipated input, but I'd really just like to make sure that my thought process is correct.

---

Your design makes good sense to me: Initialize completely or throw an exception. The only alternatives which come to mind are:

• status codes
• best-effort initialization with status member functions to find out what portions are valid

The only disadvantage which comes to mind for the all-or-nothing approach is dealing with "almost correct" input. Maybe the application would prefer a default value if an attribute is missing.