I would expect (hope) that authors of CPAN modules would habituate themselves to using "carp" and "croak" -- always -- instead of "warn" or "die" within their module code. This way, when the module hits a bad condition, the module user gets immediate feedback saying where to start looking in the calling code for the problem. The Carp module was created for just this sort of consideration, and module authors who don't use it are, quite frankly, being inconsiderate.

In fact, one possible way to assess a module's suitability would be to grep for "die|warn" and "carp|croak" in the module's perl source file(s). If you only see the latter and not the former, the module is likely to be easy to use and good enough for production code; if only the former, you might be in for some extra effort to make proper use of it (or might change your mind about using it). If you see neither (or both), use extreme caution, or look for another way to do what it's supposed to do.

I agree with jepri about the ugliness and hassle of having to wrap module calls in eval blocks to trap errors -- some modules require this (like some operations using Encode in 5.8.x), and there's probably a good reason for it in some cases, but it's still a bit ugly.

I really would expect (hope) that when a module call implements some common, familiar function (like "open(); print; close;"), it would mimic the behavior of common Perl functions that do basically the same thing: return "true" when it succeeds and "false" otherwise (with $! set to something meaningful in the latter case).

In the particular example you cited, the unchecked open is in a method called "save", whose purpose is to take the in-memory XML data object and write it as an XML stream to a named file (with file name given as an arg to the call). So as a module user, I'd like to write my code in the "normal" way:

    $xml->save($filename) or die "Couldn't save my xml data to $filena
+me: $!";
[download]

This means that the module code should have been written like this (I'll include the full source for XML::Smart->save(), because it turns out the author did include some checks for problems):

# ... near the top:
use Carp;  # THIS NEEDS TO BE ADDED
# ...

sub save {
    my $this = shift ;
    my $file = shift ;

    if (-d $file || (-e $file && !-w $file)) {
# NEED TO ADD THE "carp" CALL:
        carp "Unusable file name passed to XML::Smart->save ($file is 
+a directory or read-only file)\n";
        return ;
    }

    my ($data,$unicode) = $this->data(@_) ;
 
    my $fh;
    open( $fh, ">$file" ) or return;
    binmode( $fh ) if $unicode;
    print $fh $data or return;
    close $fh;   # save() will return true if this succeeds, false oth
+erwise
}
[download]

In this case, the author probably thought he covered all the possible failure conditions, but in fact he missed a few -- apart from the "disk-full" issue, if the module user provides a file name like "nonexistent/path/file.xml", this passes the tests for "is not a directory", and "does not exist with read-only permission".