Do note though, that would cause an interface breaking change (just in the function signatures, but still). An alternate would be to just pass in a struct that the user can subclass to perform their own error reporting, call a certain function in it or so before it finally bails out, it puts a level of indirection so if someone wants to recover they will have to use their own variables stored somewhere, so it is much more ugly and would not work well with C style bindings, whereas the interface breaking change would. Or are there any other styles that are preferred? On Mon, Sep 8, 2008 at 8:08 PM, OvermindDL1 <overminddl1 at gmail.com> wrote:>> Patches to do the kind of checking you're asking about would be >> welcome :-). I don't think it makes sense to extend the >> Verifier itself here; it's supposed to accept any valid LLVM IR. >> I think a separate CodeGenVerifier might be a good approach >> though, or possibly extending codegen itself with the ability to >> interrupt itself and yield some kind of error status. > > And I presume you all are allergic to exceptions, since I have seen > none so far (probably due to help the C bindings and such), return > error codes all over the place then? If I do any extension on this > (short on time, so good chance I cannot, but if I do) the usual > non-exception style I use is the return value is a status code, the > last argument passed in is an optional std::string* (the return code > gives the basic error reason, the string gives details), anything that > actually needs to be returned are the first arguments as > references/pointers, would that work? >
On Sep 8, 2008, at 7:18 PM, OvermindDL1 wrote:> Do note though, that would cause an interface breaking change (just in > the function signatures, but still). An alternate would be to just > pass in a struct that the user can subclass to perform their own error > reporting, call a certain function in it or so before it finally bails > out, it puts a level of indirection so if someone wants to recover > they will have to use their own variables stored somewhere, so it is > much more ugly and would not work well with C style bindings, whereas > the interface breaking change would. Or are there any other styles > that are preferred?I agree; having an abstract class interface for users to subclass sounds like over-engineering here.> > > On Mon, Sep 8, 2008 at 8:08 PM, OvermindDL1 <overminddl1 at gmail.com> > wrote: >>> Patches to do the kind of checking you're asking about would be >>> welcome :-). I don't think it makes sense to extend the >>> Verifier itself here; it's supposed to accept any valid LLVM IR. >>> I think a separate CodeGenVerifier might be a good approach >>> though, or possibly extending codegen itself with the ability to >>> interrupt itself and yield some kind of error status. >> >> And I presume you all are allergic to exceptions, since I have seen >> none so far (probably due to help the C bindings and such), return >> error codes all over the place then? If I do any extension on this >> (short on time, so good chance I cannot, but if I do) the usual >> non-exception style I use is the return value is a status code, the >> last argument passed in is an optional std::string* (the return code >> gives the basic error reason, the string gives details), anything >> that >> actually needs to be returned are the first arguments as >> references/pointers, would that work?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. Dan
> 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?