Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) 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.

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.

In reply to Re: Best Practices for Exception Handling by pg
in thread Best Practices for Exception Handling by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2024-03-28 09:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found