[LLVMdev] 2.4 Pre-release (v1) Available for Testing

[Duncan Sands]

> >> Which makes me curious, if I submitted a patch that got rid of llvms
> >> use of abort()s all over the place, and replaces them with exceptions
> >> (the program dies either way if it is unhandled, but with exceptions
> >> you at least get a chance to handle it and recover),
> >
> > since LLVM may well be left in an inconsistent state internally if
> > an exception is thrown, it wouldn't be safe to continue using it
> > after catching an exception.
> 
> The unwinding should clean things up,

yes, but it currently doesn't always.  It takes careful design to get a
system that chugs on merrily in spite of exceptions.  LLVM wasn't designed
that way.  You can of course add code to make it robust - be my guest.

> and it can be enforced in such a
> way so that, for example, the module is destroyed if such a thing
> happens.  Useful in my case because either a script compiles, or it
> fails and dies (thus returning a message back to the caller saying it
> failed, all state information I needed to keep around can be nicely
> dumped).  Exceptions are not the only method though, there are others,
> but regardless it still needs to not just 'die'...

If you just want to print some messages and then die, that would work.
There are probably many ways of getting this effect besides using
exceptions (I guess this is what you are saying in the last paragraph).

Ciao,

Duncan.