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

[OvermindDL1]

On Sat, Oct 11, 2008 at 1:24 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote:
> /* snip */

Actually, my biggest issue with llvm (which highly impacts testing as
well) is the use of abort(), which I have resolved in my local copy by
just searching for the full word "abort" everywhere and just replacing
them with exceptions that relay what happened.  Reason this is my
biggest issue is that the llvm library is just a part of the full
program that will be using it, and I cannot have llvm abort()ing on
some bad passed in code when this application needs to have the best
possible up-time, I need to send a message back to the node saying
that the compile failed, not crash.  I can understand using abort in
little one-off programs like llc or opt or something that just does
one function and ends, but llvm is a library, as such it may be in
programs that need to stay persistently up, the use of abort()
everywhere is really painful in such circumstances, even an error
handler that can be registered by the parent app into the library
would work better, although I prefer exceptions for these since they
truly are exceptional events.  Personally I also do not like asserts
either, as that is indicating you are expecting something bad to
happen; such a circumstance should have code to handle it, or throw an
exception.

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), what is the
chance it would be accepted, especially since I see no usage of
exceptions at all (even if it passes through the C api, think about
it, if an abort occurs, the program dies, if an exception is thrown
through the C api, the program still dies, either way it dies,
where-as when using the C++ interface you can at least handle it so
the parent application need not die).  Could always go with
registering an error handler with the llvm api, but that would require
more code...