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?