On 02/23/11 15:48, Barry Haddow wrote:
> Hi Ken
>
> Thanks for pointing this out. I'd always assumed that uncaught exception
> messages got printed (they do for me) so was happy to have them float up the
> stack.
I thought the same. Works for me. But then Nicola was trying to check
that their output parses with my code and not seeing my error messages.
>
> Adding such a terminate handler seems like a good idea. Are there any
> unexpected consequences? Are you just proposing to add it to the main moses
> binary?
We'll lose the name of the exception class. Printing it appears to
require RTTI or g++-specific calls. Also, while both GCC and Microsoft
agree and call it standard C++, somebody's compiler might barf on it.
There's a question of location: for my purposes this should be linked
into kenlm/build_binary, kenlm/query, moses-cmd/src/moses, etc. I see
the mert implementation and lmserver also throw exceptions, so it should
probably be linked in there as well. Where would you suggest it be
placed?
>
> btw there's a school of though which says you shouldn't use exceptions, but I
> don't subscribe to it. I think maybe this is because in the early days of C++
> exceptions didn't work properly or had performance problems. Or maybe because
> google said not to use them.
Google said not to use exceptions because their existing codebase isn't
prepared to handle them. However, they note that "new projects" could
benefit. Also, I'm responsible for getting pointer container on the
list of approved Boost libraries.
>
>
> cheers
> Barry
>
>
> On Wednesday 23 Feb 2011 20:30:27 Kenneth Heafield wrote:
>> Hiya Moses,
>>
>> There are a fair number of exceptions thrown that are not intended to
>> be caught e.g. Sentence.cpp: 107:
>>
>> if (!ProcessAndStripXMLTags(line, xmlOptionsList,
>> m_reorderingConstraint, xmlWalls )) {
>> const string msg("Unable to parse XML in line: " + line);
>> TRACE_ERR(msg << endl);
>> throw runtime_error(msg);
>>
>> I use them extensively in kenlm for file formatting issues. When an
>> exception is thrown and nothing catches it (i.e. the stack unwinds past
>> main), GCC typically prints the type of the exception and the .what()
>> string. However, the C++ standard only requires an abort() when this
>> happens. Therefore some users, apparently including Nicola Bertoldi, do
>> not see the .what() message and only see an opaque "Aborted" message.
>>
>> The solution is to link in a file like this:
>>
>> #include <cstdlib>
>> #include <exception>
>> #include <iostream>
>>
>> namespace {
>>
>> void terminate_handler() {
>> try { throw; }
>> catch(const std::exception& e) {
>> std::cerr << e.what() << std::endl;
>> }
>> catch(...) {
>> std::cerr << "A non-standard exception was thrown." << std::endl;
>> }
>> std::abort();
>> }
>>
>> struct ForceCall {
>> ForceCall() { std::set_terminate(terminate_handler); }
>> };
>> const ForceCall kForceCall;
>>
>> } // namespace
>>
>> This overrides the default handler so that the message is always
>> printed. It might be preferable to still print the type if RTTI is
>> available.
>>
>> Alternatively, main() could just be wrapped in a try/catch block; that
>> would work in most cases except static/global constructors and
>> destructors. There are 34 main() functions.
>>
>> Should I link this into the main moses binary?
>>
>> Kenneth
>> _______________________________________________
>> Moses-support mailing list
>> [email protected]
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support
