in reply to Perl etiquette - eval

It's certainly a sensible way to handle errors, in fact, the die documentation (as of 5.6+) suggests using block eval for exception handling (largely thanks to the ability to set $@ to an object). If you're familiar with the likes of Java or C++ it's similar to a try block, and an equivalent of the catch block would be subsequent manual checks of the $@ e.g 
## try some code
eval {
  do { stuff->that, might( cause => an exception() ) }
};

## catch any errors
warn "An explantion: ", $@->message if UNIVERSAL::can($@, 'can');
warn "Stuff went wrong: $@"         if $@;

[download]
HTH

_________
broquaint

Replies are listed 'Best First'.
Re: Re: Perl etiquette - eval
by flyingmoose (Priest) on Jan 16, 2004 at 15:22 UTC
    I still maintain that the use of try and catch logic in Java (and where used, C++) makes programmers lazy. Having to check for error return codes at the point of the failure means the programmer will get in the habit of writing error recovery code.

    I've seen tons of (and here is the key) badly written Java code that hits an exception and the whole program dies a horrible death with a stack trace, caught by some try/catch block that is not sufficiently fine grained.

    I rarely see this problem in C apps, where even novice programmers usually have the discipline to check return codes. In conclusion, I feel that in many cases try/catch is a crutch. Rewrite it to use standard if logic if you can. Eval has uses, but this is more of a hack than a good use. Yes, despite being a young coder punk, I'm rather old school in my software development approaches :)

    I know, you are saying this is ok in Perl and is a good idiom -- I'm just saying, it's dangerous as heck and not conducive to error recovery. Error reporting and error recovery are different things, and the latter is a lost art.

[reply]
      I'm going to have to disagree.

      First of all let me stipulate that bad programmers are going to screw up. Whatever tool you give them. The essential problem here being the programmer, not the tool.

      But with that said, in C no programmer can guarantee in complex code that error conditions are always checked. You claim that even novices know to do it. Perhaps. But even experienced programmers don't get every call right. And the resulting ignored exceptions are a persistent headache when dealing with large C applications.

      As for the behaviour of Java programs that you dislike, that is 6 of one, and a half-dozen of the other. Depending on the context, you really do want errors to cause big, visible consequences so that they can be easily noticed and fixed. In other contexts you want to log it and show a prettier face. I've personally coded both behaviours at different times, and neither is intrinsically better than the other. In one errors are more visible. In the other they inevitably become more common.

      However a personal tip. You claim to be both a young coder punk and old school in my software development practices. The tip is that one of the classic pitfalls for young coders with a lot of confidence is that they believe they can do it all. They can crank out tons of code, keeping 5 different things in mind, and get it right. Well, right after solving this one small bug, THEN it will be perfect.

      It doesn't work that way. But lots of kids manage to seriously burn themselves out before realizing it...

[reply]
        First off, I'm hardly a "kid". Secondly, You've described the anti-me. I have the least tolerance for broken code as anyone in my organization, and "hammering out code" is the antithesis of everythign I stand for. I'm a design nut.

        You used the tired "a bad programmer can screw up in every language" argument. Yes, very true... however the problem today is that new programming constructs (massive OO applications, EJB, SOAP) make it appealing and politically correct to do some very unmaintainable things. I've seen it happen. What's more, these practices are often encouraged without guarding the dangerous of over-indulgance. Some of these constructs allow interoperability between average level programmers in an organization (as is the case with massive OO), but there is a price. Sprawl. Chaos. Anti-Design in the long term. Perhaps not so in Perl as many of the Enterprise Class applications. "Enterprise Class" is usually implies "Massive OO construct with tons of exception handling", but these are also the inefficient error-prone beasts that consume 500MB of RAM. Attention to detail is lost when error checking is broad-based, and design is lost due to sprawl enabled by the lack of fine grained control and understanding.

        I am not merely ranting on try/catch, but the concept of fine-grained versus coarse-grained error recovery. Your rebuttal to mine had some very excellent points, but the "kid" part wasn't one of them. Let's not judge based on percieved experience. Nixon* had plenty of experience. * = previous read "Nikon". That would have been funny.

[reply]
        > that is 6 of one, and a half-dozen of the other.

        Excuse the OT question but does anyone know why this cumbersome idiom is becoming so common in online forums? Whatever happened to apples and oranges, or simply "no that's different"?

[reply]

      Bad Error Handling is just that, Bad Error Handling. Regardless of language and idiom.

      The idea with exceptions is that you can easily (auto-magically as my old boss used to say) allow your error to pass back up the call chain to be handled appropriately. With error return codes, you have to pass that error back up the chain yourself, which can lead to an excessive amount of unnessecary coupling.

      Don't blame the tool when the tool is used badly, blame the user.

      -stvn
[reply]
      I still maintain that the use of try and catch logic in Java (and where used, C++) makes programmers lazy. Having to check for error return codes at the point of the failure means the programmer will get in the habit of writing error recovery code.

      Surely a developer no more "has" to check for error return codes than they "have" to check for exceptions. Indeed the opposite would seem to be the case since you have to catch exceptions if you want your code to run, while returned error values can be ignored.

      I've seen tons of (and here is the key) badly written Java code that hits an exception and the whole program dies a horrible death with a stack trace, caught by some try/catch block that is not sufficiently fine grained.

      I've seen tons of terrible C and Perl code that ignores the return values of system calls and falls over in really nasty ways when something goes wrong. To-may-to. To-mah-to.

      I agree that you do get some terribly code in Java, but this is often due to the bad use of checked exceptions which many people, myself included, think are a bad idea.

      I know, you are saying this is ok in Perl and is a good idiom -- I'm just saying, it's dangerous as heck and not conducive to error recovery. Error reporting and error recovery are different things, and the latter is a lost art.

      I disagree. Indeed one of the huge advantages of exceptions for me is that they do allow you to separate error handling well. See Best Practices for Exception Handling for more in this vein.

[reply]

      > I still maintain that the use of try and catch logic
      > in Java (and where used, C++) makes programmers lazy.

      I thought Perl was all about being lazy.

      Just a tongue-tied, twisted, earth-bound misfit. -- Pink Floyd

[reply]
        Well, open ... or die "open"; is the lazy way I think. It's easier than the same in C at least.
[reply]
[d/l]

In Section Seekers of Perl Wisdom