On 2013-04-04 01:52, Russ Allbery wrote: > Niels Thykier <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
