Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^2: Style guide for error messages?

by tilly (Archbishop)
on Sep 22, 2005 at 17:38 UTC ( #494219=note: print w/ replies, xml ) Need Help??


in reply to Re: Style guide for error messages?
in thread Style guide for error messages?

And I disagree with Perl Best Practices.

The advice in PBP is designed to be one fairly good way to do things. It is not the only possible one, and it is not necessarily the best for all circumstances.

I agree that if you attempt to use exceptions as a flow of control, then it is much better to throw objects than strings. But I'd prefer that exceptions generally be fatal, and would like to discourage trying to use the exception system for complex flow of control. Which means that all of TheDamian's arguments for exception objects are arguments for how to better do what I'd like people not to do.

This is not to say that PBP is wrong. It is correct that it provides an internally consistent set of best practices. But it is not the only possible one, and it is not my preferred one.


Comment on Re^2: Style guide for error messages?
Re^3: Style guide for error messages?
by TheDamian (Priest) on Sep 22, 2005 at 23:05 UTC
    This is not to say that PBP is wrong. It is correct that it provides an internally consistent set of best practices. But it is not the only possible one, and it is not my preferred one.
    So, naturally, enquiring minds now want to know what you prefer instead! :-)
      I only got permission to quote 20 of your best practices. Doesn't quite work with the format that I wanted to use to give a comprehensive picture of exactly what practices I agree and disagree with, and why. (Unsurprisingly, I agree with more than I disagree with. And the ones that I disagree with I'd agree with in different circumstances.)

      I'm debating writing the whole thing anyways and hoping that after the fact I can get permission to post it. But that's a lot of work for what I suspect will be a "no". :-(

        (IANAL) Not sure about 'permission' and your legal geography, Tilly, (California?) but I'd be pretty surprised if even quoting all 256 in the context of a critique didn't fall easily under "fair use" provisions of US copyright law. From the link above (my emphasis):

        The 1961 Report of the Register of Copyrights on the General Revision of the U.S. Copyright Law cites examples of activities that courts have regarded as fair use: “quotation of excerpts in a review or criticism for purposes of illustration or comment; quotation of short passages in a scholarly or technical work, for illustration or clarification of the author’s observations; use in a parody of some of the content of the work parodied; summary of an address or article, with brief quotations, in a news report; reproduction by a library of a portion of a work to replace part of a damaged copy; reproduction by a teacher or student of a small part of a work to illustrate a lesson; reproduction of a work in legislative or judicial proceedings or reports; incidental and fortuitous reproduction, in a newsreel or broadcast, of a work located in the scene of an event being reported.”

        So, make it critical, scholarly, and a parody, and you should be on safe ground, regardless of what O'Reilly's lawyers say. (If you can afford the legal costs of a defense, of course...)

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        How about this. Do the article in two parts. In the first part you quote the 20 practices that you feel strongest about, and have permission for. In the second half you comment on the remaining 236 without quoting them, just giving the references to them (e.g. the number of the practice, or the page number). No need to be shy about spelling out the reason for the strange format.

        I agree with xdg that it'd be a shame if copyright laws were to effectively silence this kind of review.

        the lowliest monk

Re^3: Style guide for error messages?
by rir (Vicar) on Sep 23, 2005 at 03:56 UTC
    ... I'd prefer that exceptions generally be fatal, and would like to discourage trying to use the exception system for complex flow of control. Which means that all of TheDamian's arguments for exception objects are arguments for how to better do what I'd like people not to do.

    The emotion behind this evokes some fellow feeling but I don't find much logic in it. Exceptions are always a flow of control mechanism. Exceptions usually are fatal. Exceptions should be used to clarify flow of control. And if you must do something, distaste is not a reason to do it badly.

    Exceptions are all about passing control to unknown code.

    The type or value of an exception should rarely be needed by the handler; that is the start of a brittle, tangled mess. I use the type to carry meaning without being locked into a representation (for those rare occasions). I use the object to carry a bunch of diagnostic data.

    I use exceptions like a more robust and efficient version of the LIBNAME_STATUS variables common to old C libraries. Rarely is there any fine discrimination by the handler, usually just FAILURE vs. SUCCESS.

    Be well,
    rir

      I think we disagree on what it means to do this badly.

      First in what I do, the point of an exception is to cause a program to terminate, with a message made available (in a log, email, or on STDERR) that will give a programmer somewhere to start in fixing the problem. If that is the point, then creating an object is extra overhead that obscures what you're trying to do. Therefore for this specific scenario, creating an object is worse than just creating the message that you want to see logged. Because even though the effect may be the same, you obscured what was going on.

      In the worst case, your error handler has a mistake and you don't successfully generate an object! Yes, we should all have tests. But reality is that our error checking code tends to be the least tested, and therefore should be coded in the most simple and straightforward way possible. It is harder to not notice messing up a string than a method call, so strings are to be preferred.

      Now let's go on to the point that I initially made.

      In general when I see exception objects being created, my expectation is that someone is intending to catch those objects and process them in interesting ways. Now sometimes that might be appropriate. For instance if you want to display messages in a language-localized fashion. Or if you need to display messages after postprocessing in various ways (text message for a command line, popup for a GUI, HTML for a web form). However it is not appropriate for what I'm doing. Which raises the question of why they are being used.

      Now, as I said, I think that just constructing the final message is better because it is more straightforward. However what some people like to do is use exceptions as a general flow of control mechanism. Yes, I know that they have the capability of doing so - else they wouldn't be useful. But when people start using exceptions that way, you get into problems. Some people dislike that in all circumstances. I'm not entirely convinced of that, though I dislike the action at a distance. But the fragility of eval, $@ and die in Perl causes me to be particularly suspicious of the design idea because I know how easy it would be to just swallow exceptions rather than doing something useful with them.

      And a random point on the topic. Re: Re2: Learning how to use the Error module by example mentions specific problems with one module that tries to make exception handling cleaner in Perl. I have no idea whether others are prone to the same kinds of issues, but unless I'm given some concrete benefits, it isn't worth my energy to find out.

        Tilly, I don't think we disagree so much. I think we just think of differing situations. I was addressing xdg's concerns which seemed to indicate that string exceptions were getting messy.

        I apologize, you pretty much said all of TheDamian's arguments for exception objects are arguments for how to better use them for complex flow of control. I still think that statement is overly generalized and too prescriptive of intention, but perhaps TheDamian does argue for complex exceptional flow control. I do find some of his examples baroque. You may know Damian's intended meaning better than I. I apologize that my comments did not display any of the regard I have for the tilly you have shown here and that they reflected my ungenerous reading of your post. I guess you said "people" and I thought "Hey, I'm a people."

        But back to the issue.

        When you know the code that is going to handle, or not handle, your exceptions you are not in the situation in which exceptions shine. Exceptions are all about passing control to unknown code.

        The problem with object exceptions in Perl is that strings are the traditional default: So your expectation that something fancy is being done is reasonable. And that default makes it problematic for anyone writing a module for general use to use anything else. This will be slow to change until some exception package goes into the core. In the mean time, it is producers of larger applications who will be attracted to exception objects and those producers will be deterred by their relatively good info about what lies up the call chain, and by the need to deal with the string exceptions in modules they may use.

        The problem with string exceptions in Perl is that they are tedious and error prone to identify. Strings must be controlled by convention, Perl can help in this control if typed exceptions are used. Strings are brittle and unhelpful when you need to present your user with info that varies with some context far removed from the error. They just don't scale well. It only takes the need to discriminate a single exception from the many to start feeling this problem.

        If the optimisation (space?) is needed it is easier to factor exception objects into strings than the reverse.

        You and I could probably get by with printing a message and exiting instead of dieing. This would also make explicit that handling was not intended. Using an exception in this degenerate case promotes reusability by being flexible, using object exceptions extends this flexibility. Not using this flexibility is not misleading to me.

        Be well,
        rir

        #! /usr/bin/perl use warnings; use strict; package X; use Carp; use overload ( qq{""} => sub { return $_[0]->{description}; } ); sub new { my ( $class, $description ) = @_; $description = "Exception of type $class occurred" unless $descrip +tion; #no strict "refs"; #dprint "mutts under class" if ( 1 < @{"$class\::ISA"} ); #dprint "directly instantiated" if $class eq __PACKAGE__; bless { description => $description . Carp::longmess() }, $class; } sub caught { my $class = shift; return $class if ( $class eq ref $@ ); return; } package Eperm; use base "X"; package main; sub fail { die Eperm->new() } fail();
        ~

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://494219]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2014-08-02 05:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (55 votes), past polls