Feature Request: KeyNotFound Exception

[GoogleCodeExporter]

Is it possible to let the KeyNotFound exception to know which key was not
found? 

Original issue reported on code.google.com by n.ha...@gmail.com on 31 Dec 2008 at 2:13

[GoogleCodeExporter]

Sure - but since GetValue is templated, the key that wasn't found can be of 
arbitrary 
type. I think we'd have to template the KeyNotFound exception - but this could 
lead 
to issues when catching the exception, since, say, KeyNotFound <int> is just 
plain 
different from KeyNotFound <std::string>. What do you think?

Original comment by jbe...@gmail.com on 31 Dec 2008 at 2:42

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

For me it would be enough to "know" which Key was not found. So a std::string 
would
be normaly enough. But when it is templated I normaly know which type of Key I 
had
used, so the templated implementation shouldn't be that bad either.

Original comment by n.ha...@gmail.com on 31 Dec 2008 at 4:46

[GoogleCodeExporter]

I derived a templated TypedKeyNotFound to KeyNotFound. So to use it, you just 
do:

try {
   node["key"];
} catch (YAML::TypedKeyNotFound <std::string>& e) {
   cout << "key not found: " << e.key << "\n";
}

or something like that. If you then want to catch all other KeyNotFound 
exceptions, 
just throw on a 

catch (YAML::KeyNotFound& e)

after catching all the TypedKeyNotFound exceptions that you want. Is this OK?

Original comment by jbe...@gmail.com on 1 Jan 2009 at 2:43

• Changed state: Fixed

[GoogleCodeExporter]

Sorry, but r92 now gives me compiling errors (gcc):

[0%] Building CXX object external/yaml/CMakeFiles/yaml.dir/src/iterator.cpp.o
external/yaml/include/exceptions.h: In instantiation of
'YAML::TypedKeyNotFound<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >':
external/yaml/include/node.h:122:   instantiated from 'const YAML::Node&
YAML::Node::GetValue(const T&) const [with T = std::string]'
external/yaml/include/node.h:133:   instantiated from here
external/yaml/include/exceptions.h:83: error: looser throw specifier for 
'virtual
YAML::TypedKeyNotFound<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >::~TypedKeyNotFound()'
external/yaml/include/exceptions.h:76: error:   overriding 'virtual
YAML::KeyNotFound::~KeyNotFound() throw ()'
make[2]: *** [external/yaml/CMakeFiles/yaml.dir/src/iterator.cpp.o] Error 1

Original comment by n.ha...@gmail.com on 1 Jan 2009 at 6:11

[GoogleCodeExporter]

OK, I removed the throw() specifier from ~Exception(), but I'm not sure if 
that's the 
main problem. I don't have access to gcc right now, so can you let me know if 
it 
works?

Original comment by jbe...@gmail.com on 1 Jan 2009 at 8:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

No sorry:
[0%] Building CXX object external/yaml/CMakeFiles/yaml.dir/src/content.cpp.o
In file included from external/yaml/src/content.h:7,
                 from external/yaml/src/content.cpp:2:
external/yaml/include/exceptions.h:51: error: looser throw specifier for 
'virtual
YAML::Exception::~Exception()'
/usr/include/c++/4.2/exception:60: error:   overriding 'virtual
std::exception::~exception() throw ()'
make[2]: *** [external/yaml/CMakeFiles/yaml.dir/src/content.cpp.o] Error 1
make[1]: *** [external/yaml/CMakeFiles/yaml.dir/all] Error 2
make: *** [all] Error 2

Original comment by n.ha...@gmail.com on 1 Jan 2009 at 11:27

[GoogleCodeExporter]

All the childs of std::exception must have some methods declared with throw().
As KeyNotFound is such a child, when you inherit from KeyNotFound, you must 
declare a
destructor with throw(), like :

~TypedKeyNotFound() throw() { }

Original comment by paul.mor...@gmail.com on 1 Jan 2009 at 11:48

[GoogleCodeExporter]

Thanks, Paul, for that note. I suppose that might've been the next thing to 
try. 
Anyways, I added the throw() back in to ~Exception(), and also to 
~TypedKeyNotFound(). The stupid visual studio compiler doesn't even give a 
warning 
(at /W4) about this.

I suppose the reason it doesn't complain about not declaring a no-throw 
destructor 
for, say, KeyNotFound, is that there are no new data members, so the destructor 
is 
"essentially" the same?

Original comment by jbe...@gmail.com on 2 Jan 2009 at 12:08

[GoogleCodeExporter]

In fact I don't know much about Visual Studio compiler, as I mainly work with 
gcc.
I already have faced this error many times, but maybe it is just because gcc is 
more
nitpicky…

Original comment by paul.mor...@gmail.com on 2 Jan 2009 at 12:43

[GoogleCodeExporter]

Works now like a charm, thanks a lot.

Original comment by n.ha...@gmail.com on 2 Jan 2009 at 2:58

[GoogleCodeExporter]

Original comment by jbe...@gmail.com on 2 Jan 2009 at 5:20

• Changed state: Verified