Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Best Practices for Exception Handling

by pg (Canon)
on Jan 29, 2003 at 05:56 UTC ( #230862=note: print w/ replies, xml ) Need Help??


in reply to Best Practices for Exception Handling

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.

For error handling, there are actually two main types of methods:

  1. In the first kind of method, there is no (visual) "jump" in the control flow of your program.

    For example the try catch block, when everything is okay, it just continue with the try block, otherwise continue with one of the catch blocks, depends on the type of error;
  2. Second method is to handle errors as events. In this case, there would be a jump of your control flow, and it would be redicrected to the event handler.

    For example, in languages like basic, pl*sql, pro*c, you can define on error goto at the beginning of your program, and specify the error handler. Whenever an error is detected, the error handler will be triggered. But those are very basic, and they are still deeply different from the modern event handling. The problem of of this kind of error handling is that, the programers only have a very limited freedom and method to define what is error and who should care what error.

    The modern error handling is totally based on OO design. A typical example is the event handling in Java. It provides the entire infrastructure to define event, event producer, event consumer, event listener (there is a subtle difference between event consumer and event listener, although most of the programmers like to mix the two into one, actually event listener is the channel thru which event consumer receives the event), and of course we talk about this here, because we can define error as event.

As which method is the best, I would say the Java event handling infrastructure is absolutely the best. As that methodology fully satisfies OO principle. In this method three objects are clearly extracted: error, error producer, error consumer. The way/tool to catch error is also extracted as an object: event listener.

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.


Comment on Re: Best Practices for Exception Handling
Re^2: Best Practices for Exception Handling
by adrianh (Chancellor) on Jan 29, 2003 at 14:37 UTC

    I'm happy in my understanding of the utility of a hierarchy of error classes. I'm also happy with my understanding of event-based models.

    However, I'm reading the above as you saying that an event-based model for handling errors is better than throw/catch in the general case.

    I can understand this if you have an event-based application since there is an obvious fit - but not in the general case. Am I missing something? Misunderstanding what you said?

    Example?

      I Agree.

      But you might have missed ;-) a tiny thing in my post, I actually said that whether you could use event-driven was not just the programmer's choice, but really depended on whether your language supported it. So we are on the same page.

      At the same time, I want to stress that, if you are using things support event-driven, like Java, you should go ahead use it. It might sounds scary at the beginning, but one should try to utilize the best he can grab. After created your first event listener in Java, you would find it is actually nothing difficult.

        Sorry - still not clear :-)

        I'm still confused by what you said in your post. For example:

        As which method is the best, I would say the Java event handling infrastructure is absolutely the best. As that methodology fully satisfies OO principle. In this method three objects are clearly extracted: error, error producer, error consumer. The way/tool to catch error is also extracted as an object: event listener.

        ...

        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.

        I've written applications that are event based. In some of those event-based error handling was appropriate since the errors needed to be dealt with by other handlers.

        There's nothing stopping me doing event based error handling in perl if appropriate (you could use POE for example).

        However, I understand you to be saying (and please tell me if I'm misinterpreting :-) that in general event based error handling is "better" than try/catch error handling ("fully satisfies OO principle" vs "primitive way of error handling").

        To me the decision is a design one. If I'm producing an application with an event based model then event based error handling may well be appropriate. If I've got a message-passing or functional model, then try/catch are likely to fit the bill.

        It's a design decision, rather than a language or implementation decision.

        Assuming I'm not misinterpreting your position, can you give an example of where try/catch would fall down?

Re: Re: Best Practices for Exception Handling
by hding (Chaplain) on Jan 29, 2003 at 15:13 UTC

    Perhaps some who want to know more about error handling in general might find Common Lisp's take on it interesting, for which I refer them to a paper of Kent Pitman

      Kent Pitman's paper has moved to a new home URL:

      http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html

      This paper was originally written as an HTML document, exactly as shown below. Any final reformatting that was done for hardcopy publication in LaTeX may have been lost in this version. Any new text that has been added for this annotated version appears bracketed and in color green; such text is intended to help clarify the historical context as time passes.
      --Kent Pitman, 28-Feb-2002.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://230862]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2014-10-01 23:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (40 votes), past polls