On Sun, Oct 12, 2008 at 1:16 AM, Duncan Sands <baldrick at free.fr> wrote:> Hi, > >> 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, 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'...
> >> 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.
On Oct 12, 2008, at 7:26 AM, Duncan Sands wrote:>>>> 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.Again, while anyone is welcome to do this, it won't be accepted back into the main repository. There are better ways of accomplishing this than exceptions. Exceptions have a huge cost on the whole system and LLVM has to serve multiple clients well. -Chris
Seemingly Similar Threads
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing