Re: Stanford IDG internal Perl style
On 2013-04-04 01:52, Russ Allbery wrote:
> Niels Thykier <niels@thykier.net> writes:
>> On 2013-03-29 18:24, Russ Allbery wrote:
>
>>> * Always check the results of operations. For many functions this can
>>> be done with 'use autodie' at the start of a script or module. For
>>> anything not covered by autodie, you should add 'or die "some error:
>>> $!\n"' to the end of function calls that mail fail. For print and say,
>>> death checking is is provided by the Stanford::Infrared::Wrappers
>>> module with the functions print_fh, say_fh, print_stdout, and
>>> say_stdout.
>
>> Got a couple of questions about autodie usage now that I have had a time
>> to look at it.
>
>> What is the stance on "autodie" for non-builtins? Would you recommend
>> using for subs we write ourselves (possibly by deploying "autodie
>> hints")[1]?
>
> We haven't experimented with this at all. It seems like a reasonable idea
> to me. Mostly I just throw text exceptions with die.
>
Come to think of it, that might be an even better idea.
> For some larger, more complicated code, I've thought about switching to OO
> exception objects, since that seems to be a best practice and lets you do
> some other interesting things, like carry a lot more context information.
> It may be worth seeing whether a Lintian::Exception class combined with a
> general switch to throw/catch programming would simplify any major
> sections of code.
>
Creating a Lintian::Exception class shouldn't be much of a problem. Do
you have any recommendation on what to use as a base class (if any). I
know only of autodie::exception + Exception::Class. My limited use of
exceptions in Perl leaves me at a disadvantage here.
>> If so, why not use it for print (etc.). If not, why only limit it to
>> builtins (is it somehow flawed).
>
> The problem with print is that it's impossible to write a prototype for
> print because of all the magic that's going on. Therefore, autodie can't
> wrap it like other builtins (and say as well) and preserve existing
> behavior; some code with some calling conventions would break.
>
Ah, that makes sense. I just learned that autodie also have an issue with:
open(STDERR, '>&', STDOUT);
(requring the latter bareword to be \*STDOUT to avoid a syntax error).
But it still beats having to check every single open/close call, so... :)
> If one is willing to use a consistent style for calling print, that can be
> avoided; the easiest way to do that is to use a wrapper around print that,
> for instance, always takes the file handle as the first argument, and then
> one can either throw text exceptions or use something like autodie with
> that.
>
Turns out not even "consistent call style" can help you here:
"""
$ perl -Mautodie=print -e ''
Cannot make the non-overridable builtin print fatal at -e line 0
BEGIN failed--compilation aborted.
"""
Looks like wrapping is the only way to go with print.
~Niels
Reply to: