Missed catch?

[Joseph Turian]

I have a throw as follows:
void bar() {
ostringstream o;
o << foo;
throw o.str();
}


I used to catch it is follows:
void baz() {
try {
bar();
} catch (string s) {
cerr << "CAUGHT";
}
}

That worked just fine. But when I moved the 'try ... catch' block to
main() (which calls baz()), the exception is NOT caught. I just get a
terminate.
Why is that? How can I catch the exception in main?

Thanks,
Joseph

 

[mlimber]

I have a throw as follows:
void bar() {
ostringstream o;
o << foo;
throw o.str();
}


I used to catch it is follows:
void baz() {
try {
bar();
} catch (string s) {
cerr << "CAUGHT";
}
}

That worked just fine. But when I moved the 'try ... catch' block to
main() (which calls baz()), the exception is NOT caught. I just get a
terminate.
Why is that? How can I catch the exception in main?

Thanks,
Joseph

First of all, you should not throw an object (such as std::string)
whose copy constructor might also throw. That's a recipe for disaster
and possibly the cause of your woes here. See
http://www.boost.org/more/error_handling.html for some excellent advice
on how to use exceptions properly.

Second, you should catch by (const) reference. See this FAQ and the
following one:

http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.6

Third, there is no issue with having the code above in main() instead
of baz(), except for those issues already mentioned. Show us a
complete, compilable example that demonstrates your problem, and we
might be able to help further.

Cheers! --M

 

[Joseph Turian]

I read the documents you cited and tried the changes you proposed.
However, no luck.

Here's actual excerpts from the code:

class l1_exception : public exception {
};

....

l1_exception l1ex;
void parameter::set_l1_penalty_factor(double d) {
...
if (parameter::l1_penalty_factor() <
parameter::final_l1_penalty_factor()) {
throw l1ex;
}
...
}

// The following catch is successful
try {
parameter::set_l1_penalty_factor(max_gain() *
parameter::l1_penalty_factor_overscale());
} catch (l1_exception& e) {
exit(0);
}

// If we comment out the above catch, the following catch in main()
misses:
try {
train(type, example_file);
} catch (l1_exception& e) {
exit(0);
}

I get the following terminate() message:
terminate called after throwing an instance of 'l1_exception'
what(): 12l1_exception


How can I correct the catch in main()?

Thanks,

Joseph

 

[Joseph Turian]

I get the following terminate() message:
terminate called after throwing an instance of 'l1_exception'
what(): 12l1_exception

hmmm... so if I compile *without* -fomit-frame-pointer, I catch the
exception just fine.
Why is this?

Joseph

 

[Thomas Tutone]

Here's actual excerpts from the code:

[snip]

Joe -

If you want anyone to help you, you're going to have to comply with
MLimber's request. What you posted is not a "complete compilable
example that demonstrates your problem." Please help us help you.

Best regards,

Tom

 

[Larry I Smith]

hmmm... so if I compile *without* -fomit-frame-pointer, I catch the
exception just fine.
Why is this?

Joseph

A frame is required for exception handling to work across function
calls.

Larry

 

[Thomas Tutone]

Joseph Turian wrote:

A frame is required for exception handling to work across function
calls.

Larry

I'm not sure I follow you. Are you suggesting that
-fomit-frame-pointer prevents exception handling across function calls?
It seems to work for me.

Best regards,

Tom

 

[Larry I Smith]

I'm not sure I follow you. Are you suggesting that
-fomit-frame-pointer prevents exception handling across function calls?
It seems to work for me.

Best regards,

Tom

Perhaps it is hardware/OS related?

This snip from the GCC 'info' pages seems to suggest
the frame and exceptions are inter-related on some platforms.

`-fexceptions'
Enable exception handling. Generates extra code needed to
propagate exceptions. For some targets, this implies GCC will
generate frame unwind information for all functions, which can
produce significant data size overhead, although it does not
affect execution. If you do not specify this option, GCC will
enable it by default for languages like C++ which normally require
exception handling, and disable it for languages like C that do
not normally require it. However, you may need to enable this
option when compiling C code that needs to interoperate properly
with exception handlers written in C++. You may also wish to
disable this option if you are compiling older C++ programs that
don't use exception handling.

The OP's question should probably be directed to the newsgroup:

gnu.g++.help

Regards,
Larry