What about Exceptions?
BlitzMax Forums/BlitzMax Programming/What about Exceptions?
| ||
| In my next (epic) module, I'm planning of utilizing the power of Exceptions for all the internal error handling/generation. It would be up to the programmer to wrap calls into the module with Try/Catch in order to handle any exceptions coming from deep within. (Or not, except then you'll likely get an Unhandled Exception error) Personally, I think Exceptions aren't being used as much as they could be. They are very useful tools, and, since you can create your own type to hold whatever details you see fit, they can end up being useful to the programmer at the higher levels. In my current tests, they are working very well - and help with debugging too, funnily enough. Anyone have any opinions good/bad on using Exception-driven code ? :o) |
| ||
| They're useful if your function or whatever can't return an error, either because it just doesn't return values (constructors) or any value it does return might be considered valid (like a timing or random function). |
| ||
| Exception driven code is nice and I think really important, but bugfree code thought is better :) What I mean is that try - catch must not be used for anything. Only use it at critical parts. (throw if media missing after load, initial fail etc) Its better to use Assert in debug mode and kill as many bugs as possible through clearly stated and ensure pre- and post requirments (and invariant checks) |
| ||
| Agree to have bug free code. However, I wrapped my whole main loop in Try Catch for final release (I take it out when coding/debugging) and then if an unexpected error (say with the graphics driver) occurs, I'll get an error instead of a bomb. Only problem is most errors are just MAVs, but when a customer got one, I sent a debug version of the .exe and then they get a proper error message which I was able to track the problem and kill it with. I also have a global integer that I set to different values in various places in the code, this can be outputted on the error message to give you an idea where program flow was when the error occured - very useful. |
| ||
| I wrap pretty much every method and function in a try block and kick exceptions out to a log file. This helps let rare but non-critical bugs simply slip past unnoticed, but it also helps me pinpoint exactly where things went wrong when an app -does- crash. If I'm hacking together a particularly nasty kludge, I'll drop several try blocks into a method to help narrow the list of culprits. |
| ||
| Wherefor several try blocks? You can throw without beeing in a try block and if you try on the "main level" and have a general error / exception handler, this will actually do the job as good just a lot cleaner ... |
| ||
| I like the fact that I can populate my Exception Type with all the (what I think are) relevant details at the point I need to throw it. |
   |