Re: return eval { die() } idiom

[benn]

I think this depends on the general error handling strategy of the whole application. When developing and working out the 'nitty-gritty' in subs, modules etc. (especially with command-line-based apps), I like the code to die there and then.

Eventually though, once the errors (hopefully!) are down to being only those that are likely to be thrown by strange input/ system failures etc. (rather than buggy code), I'll fit the error handling into the 'bigger picture' - this could be "report to user and die", but it may also be "report to user, but ignore and continue", "report via email to sysadmin and ignore", "report to eveybody in 100m radius and SHUT DOWN THE POWER NOW GOD DAMMIT LETS GET THESE PEOPLE OUTTA HERE!!" etc.

Where this reporting (or not) happens is then just a matter of personal preference. Some people like to call "Report_Error($error)" everywhere, while some people like to check return values and report in a single place (as part of the 'main loop' logic say). The 'C-style' code you demonstrate is appropriate for the latter - if the sub failed, the error can be propagated up nicely and the 'main logic' can take the appropriate action - trying another sub for instance, rather than having the failing sub dictate its own strategy.

Cheers, Ben.