Question: 'set_new_handler(terminate)' removes need to handle std::bad_allocexception?

[Asfand Yar Qazi]

Hi,

Just wondering, if I do a:

std::set_new_handler(std::terminate)

I won't have to worry about a std::bad_alloc being thrown when I do a
'new ...' or a 'new(nothrow) ...', right?

Its just that I'm writing a Ruby extension, and I tried wrapping C++
code in a generic exception-catching net, but it broke (I got all sorts
of wierd and not-so-wonderful errors.) It seems that Ruby uses
setjmp/longjmp for exceptions, and that is incompatible with the G++
3.2.2 way. Oh well...

Thanks in advance,
Asfand Yar

 

[Attila Feher]

Hi,

Just wondering, if I do a:

std::set_new_handler(std::terminate)

I won't have to worry about a std::bad_alloc being thrown when I do a
'new ...' or a 'new(nothrow) ...', right?

Its just that I'm writing a Ruby extension, and I tried wrapping C++
code in a generic exception-catching net, but it broke (I got all
sorts of wierd and not-so-wonderful errors.) It seems that Ruby uses
setjmp/longjmp for exceptions, and that is incompatible with the G++
3.2.2 way. Oh well...

The setjmp/longjmp pair is incompatible with any C++ code using non-trivial
classes. Anyway I think that setting the new handler to terminate should
avoid bad_alloc. However it will not avoid things. If you do get a longjmp
while you are in C++ code _none_ of your desctructors will run. I mean if
the longjmp jumps over the C++ code back to the original calling C. Also,
it will only avoid this particular exception, in this particular case. So
if you use the Standard Library or anything else using exceptions you are
better off having a catch(...) on your C++ functions (I guess they are
callbacks from C?) and turn those exceptions into something Ruby can
understand.

 

[Asfand Yar Qazi]

The setjmp/longjmp pair is incompatible with any C++ code using non-trivial

classes. Anyway I think that setting the new handler to terminate should
avoid bad_alloc. However it will not avoid things. If you do get a longjmp
while you are in C++ code _none_ of your desctructors will run. I mean if
the longjmp jumps over the C++ code back to the original calling C.

Thanks for the heads-up: I didn't know that. This is only for stuff
allocated on the stack, right? If I compiled Ruby with C++ instead of
C, would this problem remain? I mean, I'd be moving from C++ to... C++!

As for the destructors problem with regards to heap allocated objects,
Ruby has its own garbage collector, and allows one to specify ones own
freeing routine, so I just pass it a pointer to a 'void
delete_MyType(MyType* p) {delete p;}' function along with the objects
pointer, and it frees it OK.

Also,
it will only avoid this particular exception, in this particular case. So
if you use the Standard Library or anything else using exceptions you are
better off having a catch(...) on your C++ functions (I guess they are
callbacks from C?) and turn those exceptions into something Ruby can
understand.

That's what I'm saying: I already tried that 'wrapping' and for some
strange reason, it really mucked up Ruby's internal state.

Thanks,
Asfand Yar

 

[Alexander Terekhov]

Hi WW,

Attila Feher wrote:
[...]

The setjmp/longjmp pair is incompatible with any C++ code using non-trivial
http://www.codesourcery.com/archives/c++-pthreads/msg00126.html

classes. Anyway I think that setting the new handler to terminate should
avoid bad_alloc. However it will not avoid things. If you do get a longjmp
while you are in C++ code _none_ of your desctructors will run. I mean if
the longjmp jumps over the C++ code back to the original calling C. Also,
it will only avoid this particular exception, in this particular case. So
if you use the Standard Library or anything else using exceptions you are
better off having a catch(...) on your C++ functions (I guess they are
callbacks from C?) and turn those exceptions into something Ruby can
understand.

http://www.codesourcery.com/archives/c++-pthreads/msg00291.html

regards,
alexander.

 

[Attila Feher]

Hi WW,

Attila Feher wrote:
[...]

The setjmp/longjmp pair is incompatible with any C++ code using
non-trivial
http://www.codesourcery.com/archives/c++-pthreads/msg00126.html

classes. Anyway I think that setting the new handler to terminate
should avoid bad_alloc. However it will not avoid things. If you
do get a longjmp while you are in C++ code _none_ of your
desctructors will run. I mean if the longjmp jumps over the C++
code back to the original calling C. Also, it will only avoid this
particular exception, in this particular case. So if you use the
Standard Library or anything else using exceptions you are better
off having a catch(...) on your C++ functions (I guess they are
callbacks from C?) and turn those exceptions into something Ruby can
understand.

http://www.codesourcery.com/archives/c++-pthreads/msg00291.html

In theory.. :-(

 

[Asfand Yar Qazi]

Bog it all to Hell - I'm getting the aborts out!

Waiting for a scripting language compatible with C++ exceptions,
Asfand Yar