Re: The art of error handling

On this subject, I have seen code where the developer used prototyped subs to mimic try/catch exception handling:

try {
   open(TEST, ">$file");
};
catch {
   push(@errors, "Failed to open $file");
   return undef;
};
[download]

This basically eval()s the try block, and the catch checks the value of $@. Is this good style? I would think that the eval() overhead would be prohibitive, that is why I have avoided using it.

Hot Pastrami

Comment on Re: The art of error handling Download Code

Replies are listed 'Best First'.
aliasing keywords by Anonymous Monk on Dec 20, 2000 at 03:09 UTC
It's not particularly good style, IMO. The reader has to constantly remind themselves what your particular definition of try and catch do (in particular, what their side-effects are). Such temptations exist in other languages as well ... have you ever had to maintain e.g. C code where the original programmer decided to `#define` their own aliases for standard C keywords, perhaps in imitation of some other language? `eval {}` and `if ($@) {}` may not be quite as attractive, but it is immediately clear to anyone with appreciable perl experience what they do (including side-effects). Fewer bytes too. ^_^	[reply] [d/l] [select]

Replies are listed 'Best First'.

aliasing keywords
by Anonymous Monk on Dec 20, 2000 at 03:09 UTC

It's not particularly good style, IMO. The reader has to constantly remind themselves what your particular definition of try and catch do (in particular, what their side-effects are).

Such temptations exist in other languages as well ... have you ever had to maintain e.g. C code where the original programmer decided to #define their own aliases for standard C keywords, perhaps in imitation of some other language?

eval {} and if ($@) {} may not be quite as attractive, but it is immediately clear to anyone with appreciable perl experience what they do (including side-effects). Fewer bytes too. ^_^

[reply]
[d/l]
[select]