Re: WIN-18: remove exception.cc dependancy on libstdc++-v3 headers

[Andrew Haley <aph at cambridge dot redhat dot com>]

Jeff Sturm writes:
 > On 10 Feb 2002, Adam Megacz wrote:
 > > Given that it's so small, I figure that removing this dependancy is a
 > > good thing -- it means that libjava can be ported to platforms where
 > > libstdc++-v3 doesn't work (cough, cough, mingw...)
 > 
 > Besides, if I don't care about libstdc++ I shouldn't need to wait for
 > the build.  That's what ought to happen if I configure with
 > --enable-languages=c,java: build the cp frontend but not its runtime.
 > 
 > > 2) Hack a std::abort() before #including unwind-pe.h, since unwind-pe
 > >    assumes that if you're compiling with a C++ compiler, you
 > >    automatically must have libstdc++-v3 available (faulty assumption,
 > >    IMHO).
 > 
 > hmm... I see there's no way to test for the existence of #pragma
 > java_exceptions.  Too bad.
 > 
 > To be honest I'm not sure an abort() here is the right thing to do.  Is
 > any failure in EH truly catastrophic?

Yes, it is.  I don't believe you will find anything better than
aborting.

 > If not, I don't want to terminate my process, I'd rather terminate
 > the current thread (and release locks) if it cannot continue.
 > 
 > (I know the abort isn't supposed to occur, but consider that my Java
 > applications runs 24/7 and I'd prefer it to limp along in a crippled state
 > than quit completely.

That depends.  When the EH is totally corrupted it makes far more
sense to abort: at that point a 24/7 app would need to be restarted
from its last checkpoint.  That's the only secure thing to do in such
a situation.

 > Even with Sun's VM I get a MTBF of about 1 month; I'm hopeful that
 > gcj can do better.)

Sure, but continuing with a broken EH context is not how you get
reliability.

Andrew.