use Perl

• Why undef? (Score:1)

  by ChrisDolan (2855)

  How is returning undef better than dying? It sounds like a step backward to me. Is there a reason for that choice?
  
  • Re:Why undef? (Score:1)

    by Alias (5735) on 2006.05.18 11:49 (#47758) Homepage Journal

    A die would indicate an exception, something we don't expect to happen.
    
    In fact, File::HomeDir already has a number of these in it. Generally, it's things like failing to find a directory where it is expecting one. If someone hacked their OS X directories to something unusual, you might see it.
    
    However, as I push outwards to try and cover more platform and situations, I'm finding that lack of a home directory is much much more common than I had thought (or than the original author thought as well I suspect).
    
    It's reached the point where I think people are going to have to think about dealing with it in order to have their module available to a reasonable group of platforms.
    
    For example, if you try to install a module on OS X as root, well then there's no home directory for it, and tests are going to fail. Currently, they die, so they fail at File::HomeDir itself. Any problems further up will so far have been masked.
    
    But in any case, not having a home directory isn't looking like an exception-to-the-rule at all.
    
    So we have two possibilities.
    
    1. Die and tell people that they need to care.
    2. Return false.
    
    If we do 1. then people will need to do something like this every time you call a File::HomeDir method.
    
my $home = eval { File::HomeDir->my_home; };
if ( $@ ) {
        # Trap the no homedir case, and rethrow the rest
        if ( $@ =~ /does not have a home directory/ ) {
                  # handle that case ...
        } else {
                die $@;
        }
}

    If you DON'T trap the case, it dies.
    
    That code is pretty evil. So the alternative of a "normal" false return is better.
    
    We can't return the normal boolean false null string, because that is going to be legal as "current dir" in some expressions, or otherwise not error properly.
    
my $home = File::HomeDir->my_home;
my $conf = "$home/.foo";

    IF we use a null list, then this gets broken...
    
my $conf = File::Spec->catdir(
        File::HomeDir->my_home,
        '.foo',
        );

    Which leaves undef. It will work in boolean cases...
    
my $home = File::HomeDir->my_home
        or die "You don't have a home directory";

    But also, it will create plentiful warnings or outright exceptions get thrown when it is used but isn't checked.
    
    So it's mostly a case of looking out for the both the DarkPAN and people writing new code. If there is a lot of code out there that currently assumes a true return, then returning undef is the best combination of "induces failures" + "compact to code against" I can think of.
    
    I'd be open to something better though

    Reply to This

    Parent