Please make throw optional (ie support build without exceptions)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Include standard yaml-cpp headers from a c++ file and build with gcc using 
-fno-exeptions

What is the expected output? What do you see instead?
The build breaks with the following error:

In file included from /usr/include/yaml-cpp/node.h:132:0,
                 from /usr/include/yaml-cpp/yaml.h:13,
                 from /home/dev00/dev/cpp/PuzzleGame/DuckLib/DuckUtils/ObjectLoader.cpp:10:
/usr/include/yaml-cpp/nodeimpl.h: In instantiation of ‘const YAML::Node* 
YAML::Node::FindValue(const T&) const [with T = std::basic_string<char>]’:
/usr/include/yaml-cpp/nodeimpl.h:69:36:   required from here
/usr/include/yaml-cpp/nodeimpl.h:33:26: error: exception handling disabled, use 
-fexceptions to enable

I would really appreciate an #ifdef or equivalent to make sure "throw" 
statements can be left out. I know this can leave some errors undetected but 
it's a requirement to have exceptions disabled in my project. Having some error 
state to check or some return value wherever possible would be ideal.

What version of the product are you using? On what operating system?
yaml-cpp 0.3.0 from portage on Sabayon Linux 64-bit

Please provide any additional information below.
grepping for "throw" in the "include" directory yields:
./node/detail/impl.h:64:                    throw BadSubscript();
./node/detail/impl.h:92:                    throw BadSubscript();
./node/detail/impl.h:135:                    throw BadInsert();
./node/impl.h:106:                throw TypedBadConversion<T>();
./node/impl.h:111:            throw TypedBadConversion<T>();
./node/impl.h:122:                throw TypedBadConversion<std::string>();

Original issue reported on code.google.com by de...@gmx.it on 7 Apr 2013 at 5:59

[GoogleCodeExporter]

Just to clarify: would you be OK with exceptions thrown in a .cpp file? Can you 
link -fno-exceptions code with code that throws an exception? What happens when 
an exception is thrown? (Presumably it crashes - and why is that better than 
just enabling exceptions?)

Original comment by jbe...@gmail.com on 7 Apr 2013 at 6:52

[GoogleCodeExporter]

Yes, having exceptions in the binaries would fix my problem.
AFAIK, disabling exceptions is non-standard so the outcome is 
compiler-dependent. I think it's reasonable to expect the program to crash and 
probably log something to stdout. For me however it's acceptable to treat these 
cases as bugs (users won't be allowed to tweak data files anyways), and as such 
exceptions shouldn't occur.

Exceptions do have a overhead, and as of now I'm not using them anywhere in my 
code. From my researches though, this overhead is smaller than what most people 
think (see http://lazarenko.me/2011/07/22/c-exception-handling-and-performance/ 
and http://www.gamearchitect.net/Articles/ExceptionsAndErrorCodes.html) so I'm 
thinking to get out of the 90s and start using them, but I have other 
priorities for now and my current code is not always exception-safe.

Original comment by de...@gmx.it on 8 Apr 2013 at 2:06

[GoogleCodeExporter]

Exceptions are tied very closely with parsing, so I don't think I want to 
remove them. Sorry :(

Original comment by jbe...@gmail.com on 13 Apr 2013 at 6:01

• Changed state: WontFix

[GoogleCodeExporter]

Your previous question made me think about the whole exceptions matter and 
after researching I've found out that propagating errors in c-style is often 
slower than using exceptions, so I decided to enable them and fix my code to be 
exception-safe. I'm adding this comment for other people who might be 
interested.

Zero overhead exceptions only have a bad effect on the binary size. However the 
extra storage is kept away from code so it doesn't affect cache. You only have 
a slowdown when an exception arises, which is ideally never. Refer to my 
previous links (and the links within) for more informations.
The only case where I think error codes still make sense is in embedded 
software development, but then I doubt you'd be using yaml at all.

Original comment by de...@gmx.it on 15 Apr 2013 at 8:26