Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^2: Best Practices for Exception Handling

by adrianh (Chancellor)
on Jan 29, 2003 at 14:37 UTC ( #230955=note: print w/ replies, xml ) Need Help??


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

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?


Comment on Re^2: Best Practices for Exception Handling
Re: Re: Re: Best Practices for Exception Handling
by pg (Canon) on Jan 29, 2003 at 16:32 UTC
    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?

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (8)
As of 2014-07-30 05:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (229 votes), past polls