Re^2: 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

Replies are listed 'Best First'.
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.	[reply]
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?	[reply]