|Do you know where your variables are?|
Re: Best Practices for Exception Handlingby pg (Canon)
|on Jan 29, 2003 at 05:56 UTC||Need Help??|
Here we actually have a mixture of two things, error handling and event handling. When error handling is about the purpose, event handling is more like a kind of method. They are mixed, because in some languages, it is possible for you to handle error as a type of event.
In this way, the structure of your application is crystal clear, and you can easily break the application into small managable pieces, and those pieces can be easily designed, developed and maintained by multiple persons/teams, which fully satisfies the modern software design and project management principles.
All your code can be easily reused. As everything is object, you can easily start with generic classes and gradually go down to more and more specific subclasses, and reuse whatever you defined at generic levels, at any more specific levels.
For example, you can have an Error class, which covers all errors, then have a subclass called MalFormedURLError, and you can define attribute error_code, method set_error_code/get_error_code in Error class, thus being inherited in MalFormedURLError class.
try catch block is a kind of very primitive way of error handling. It does not provide much benefit, in terms of reusing code and OO design.
Well you can reuse some code, for example, to put your error handling code in a function, and call this function from more than one catch blocks. This is a kind of reuse, but very primitive.
However, whether you can do it in a modern event handling way, is not really just your choice, it also depends on whether your language supports it.
Perl is based on c, and unfortunately c and c++ does not provide strong support for event handling (although the base is there, but it does not go much higher). Java did a lot of work on its own, and changed the entire event handling into a kind of art.
But we still see some event handling in Perl, for example Tk is event driven. Another example would be signal handling.
Another thing worths to mention is that, lots of c/c++ programmers actually use an alternative way to mimic modern event handling to a certain level, that is to heavily utilize the concept of call-back function, thus allow the user of a package to define/overwrite the default error handling behavior provided in libraries/packages.