2

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

kmore
  • 884
  • 9
  • 18
  • RAII is great and all but I prefer trivial constructors. If you are opening files, connecting sockets, or doing any other failure prone non-allocation logic in the constructor then you should throw. – AJG85 Jul 11 '11 at 15:40
  • Trivial constructors are great for trivial things, since they're not prone to the exceptional cases you mention. The only thing that I could think of that would belie your argument for trivial constructors is an out-of-memory exception...that's very possible in a constructor that allocates memory, but I suppose when you say 'trivial constructor,' you probably don't mean one that allocates any memory for class members. – kmore Jul 11 '11 at 16:21
  • I just wanted to point out that having a constructor that creates many objects, opens files, parses xml, checks the input for validity, etc, etc might as well be a gigantic do everything function which to me goes against object oriented principles. – AJG85 Jul 11 '11 at 23:16

1 Answers1

1

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.

wallyk
  • 53,902
  • 14
  • 79
  • 135
  • Thanks for the confirmation. The nature of the input requires an all-or-nothing approach, because if there's any error in the way the file is formatted, nothing else in this module will make any sense. – kmore Jul 14 '11 at 08:27