Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: use Fatal;

by Masem (Monsignor)
on Jan 10, 2002 at 10:28 UTC ( #137684=note: print w/ replies, xml ) Need Help??


in reply to use Fatal;

Generally, yes, given an operation that might fail, you'd like to catch and die on all errors. But there are cases where you maybe want to see if there's failure, but do nothing about it if there is. For example, in the generation of the perlmonk maps, I query a remote server for the cloud images. If the server doesn't respond, I simply ignore it and go on since the maps can be generated without it. On the other hand, if the user list from PM isn't available, then making the maps would be pointless, and I'd want to die there. EG:

$clouds = get_clouds( $server ); # note no die if ( $clouds ) { $options{ clouds } = $clouds; } $users = get_users( $server ) or die "Cannot connect to user list" if ( $users ) { $options{ users } = $users; } #not neccesary but nice +ly parallel

So, IMO, it's nearly always better to explicitly state the die condition than to group them into one. While 90% of the time you may not have to worry about special cases, if you find the need to , you'll have to do a lot of code modification in order to get the special case to work.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important


Comment on Re: use Fatal;
Download Code
(tye)Re3: use Fatal;
by tye (Cardinal) on Jan 10, 2002 at 11:38 UTC

    While 90% of the time you may not have to worry about special cases, if you find the need to , you'll have to do a lot of code modification in order to get the special case to work.

    Most of the items that Fatal is advertised for only return a "success/fail" value so it is completely trivial to handle the 10% cases. If you look at the return value, then the call isn't fatal. If you don't look at the return value, then the call is fatal.

    Calls that return vital information that can also be an error indication aren't as well suited for the type of error handling change that Fatal imposes and so I don't include those in my proposal above. Note that some of the calls do return information, but that information is not vital.

    For example, I don't include fork because there usually isn't much point in calling fork in a void context. Since you pretty much have to check the return value from fork (to decide if you are now the parent or the child), you usually also manage to check for the error case. The value returned by fork is "vital".

    Now, some invocations of open can return interesting information, such as a process ID. But that information isn't vital. It is very common to check the return value of open only for whether it failed or not. And people (unfortunately) often use open in a void context. So making open (in a void context) "fatal" can be a great way to find hidden errors.

            - tye (but my friends call me "Tye")
Re^2: use Fatal;
by Aristotle (Chancellor) on Jan 10, 2002 at 21:05 UTC
    Excuse my potential ignorance, but I'm wondering - for cases when you want explicit checking, couldn't you trap failures using eval {}? Then this:
    open(FILE1, "<file1"); open(FILE2, "<file2") or die "Can't open file2: $!\n";
    is the same as this:
    use Fatal qw(open); eval { open(FILE1, "<file1"); } open(FILE2, "<file2");
    no?
      That is a very ugly use of eval, IMHO.

      I've nothing wrong with the eval function, but I'm of the opinion that eval should be used for code that might be generated on the fly (most likely from user input), thus implying the dynamic nature of the perl language. Using eval to evaluate code that is already hard written into the code, on the other hand, seems to be a way to get around compiler/strict or other issues. Certainly there are cases where using eval on hard-coded code is necessary to achieve certain results (for example, if you have a function from a module that would die on failure, but you want to catch this), but otherwise, it reminds me of when I saw C or C++ code that was wrapped in pragmas in order to disable certain compiler features to get their badly written code working properly.

      IMO, and I think it will be easier in perl 6, I'd much rather move to an OO-based Exception model as Java has, as it forces you to deal with errors, instead of allowing them to slip. This way, you can deal with errors that might be generated from one part of the code differently than errors from other parts. It does require you to think about these errors from the start, but it ends up improving your overall error-catching of the final program.

      -----------------------------------------------------
      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      "I can see my house from here!"
      It's not what you know, but knowing how to find it if you don't know that's important

        Ah. Well personally, I've always thought eval BLOCK should not exist, and that this functionality should be provided by a try BLOCK function. :-)
        eval BLOCK and eval STRING have as much in common as select FILEHANDLE has with the four-argument version, in my opinion. Since the block contents are known at compile time, they're compiled. Since string contents can't be known at compile time, they must be compiled at run time.

        I do agree that using eval to catch death from the Fatal module is particularly ugly.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2014-12-27 11:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (177 votes), past polls