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. 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. > 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. 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. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
