Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re: Re: Re: Best Practices for Exception Handling

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

in reply to Re^2: Best Practices for Exception Handling
in thread Best Practices for Exception Handling

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.
  • Comment on Re: Re: Re: Best Practices for Exception Handling

Replies are listed 'Best First'.
Re^4: Best Practices for Exception Handling
by adrianh (Chancellor) on Jan 29, 2003 at 18:16 UTC

    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?

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2021-10-27 08:05 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (91 votes). Check out past polls.