[LLVMdev] Integer questions

[OvermindDL1]

> I agree; having an abstract class interface for users to
> subclass sounds like over-engineering here.

The advantage of having another class handle such a thing is that
errors that can be recovered from can continue, where as pretty much
any other form of error handling handles it after it already bails.

> I don't know what the best approach is. It would need to be something
> that doesn't interfere with users who don't need it, and presumably it
> would need to be good enough to meet your needs.

I just consider some form of error reporting that reports an error by
killing the program in some form, "very bad".  I would accept anything
that just says "Unknown Error", as long as it does not kill the
program (why does it do that anyway?), but would prefer some form of
detailed reporting so I could at least tell the user what was wrong so
they can fix it while the program is running and have it be reloaded
in real-time (yes, the format of my little language does allow new
code to be added during run-time, as well as updating old code, the
style the language is used in allows that to be done with little
issue).

I do not suppose I could just go the cheap route and replace all the
assertions and abort's with a macro that does an
assert/abort/exception depending on whether something is define'd or
not?  Would not break anything, it would act identically to as it does
now if no one adds that defined word to their build, and I could get
'good-enough' information from the exception, although with no chance
of recover, would have to restart the operation.  This is a bit of a
monstrous hack, but considering the current form of error reporting is
even worse, and this would probably take well less then an hour of
work, I would settle for it until something better is made...

I do have to ask though, who thought "abort"ing the program was good
error reporting?