Often, I need to use this library to parse user provided files. This means that I want my program to give useful error messages if these files are ill-formed. This can happen in two ways: the files are not proper YAML, or they are proper YAML but the data contained is not in the correct format. In the former case, I expect yaml-cpp to throw an exception, ideally saying where the error is as best it can, that I can then catch and do with it what I want (ie. show its what() to the user). In the second case, many scenarios can be covered by placing a node in an if statement or using Is<something>() methods, but some would be best covered with other exceptions. For example, if I call as<unsigned>() but the value provided in the YAML file is not an unsigned integer, an exception that I can catch would be useful, for it would make cleaner code than transforming the value into an std::string and converting it myself. Right now, many of these exceptions appear to be in place, but because the documentation says nothing about them (unless I'm blind), I need to assume it is basically undefined behaviour, meaning the library is free to do whatever it wants without it being a breaking change, and may change at any time, thus making these exceptions useless. Are they basically undefined behaviour? If so, this is a feature request to standardize them. If they are not, then this is a feature request for documentation on this part of the library.
Often, I need to use this library to parse user provided files. This means that I want my program to give useful error messages if these files are ill-formed. This can happen in two ways: the files are not proper YAML, or they are proper YAML but the data contained is not in the correct format. In the former case, I expect yaml-cpp to throw an exception, ideally saying where the error is as best it can, that I can then catch and do with it what I want (ie. show its what() to the user). In the second case, many scenarios can be covered by placing a node in an if statement or using Is<something>() methods, but some would be best covered with other exceptions. For example, if I call as<unsigned>() but the value provided in the YAML file is not an unsigned integer, an exception that I can catch would be useful, for it would make cleaner code than transforming the value into an std::string and converting it myself. Right now, many of these exceptions appear to be in place, but because the documentation says nothing about them (unless I'm blind), I need to assume it is basically undefined behaviour, meaning the library is free to do whatever it wants without it being a breaking change, and may change at any time, thus making these exceptions useless. Are they basically undefined behaviour? If so, this is a feature request to standardize them. If they are not, then this is a feature request for documentation on this part of the library.