in reply to What Are The Rules For Subs And Modules When Fed Wrong Input

Return an error value. If it's really, really important, write a message to STDERR or a log file (not STDOUT!). Library code should never, never, NEVER die on any error condition short of the CPU bursting into flames (and even then it's questionable). What you consider to be a fatal error may be a normal condition for the programmer using your library/module. (Yes, I've had the supreme displeasure of using a library which "helpfully" terminated my programs whenever an error occurred without giving me a chance to detect and correct the situation, or at least perform a controlled shutdown.)

Oh, and another thing re: the examples under question 4 - the user should never be subjected to detailed information about the programmer's mistakes. It will just confuse them. (*ring* *ring* "Hello, tech support." "Your program just said, 'Wrong number of parameters! Correct syntax is my_sub($name,$phone,$address)', but I filled in all the blanks on the form. And WTF does 'my_sub' mean?")

  • Comment on Re: What Are The Rules For Subs And Modules When Fed Wrong Input

Replies are listed 'Best First'.
Re: Re: What Are The Rules For Subs And Modules When Fed Wrong Input
by PhiRatE (Monk) on Jul 22, 2002 at 01:16 UTC
    I disagree. Die. Always die. Die on everything except success.

    The reasoning behind this is simple. Its easy to handle an exception, you can catch it, you can ignore it, you can re-throw it. All of this without cluttering the interface with random error variables and having to test returns at every single operation.

    Exceptions didn't catch on for no reason, they are an elegant and effective method of error handling and indeed I find myself having a very hard time writing software in languages that don't support them.

    Let us take the example of a database error for example. If the DBI module threw useful exceptions when things went wrong, I would no longer have to sit there checking the return on every little operation to make sure things went ok. I could wrap my entire atomic operation in an eval {}, catch any exceptions I found relevant and re-start the entire operation or provide *useful* input to the user if necessary. Easy, clean, effective.

    Think twice before dissing die(), its a big strength. That said, no interface should die() without the documentation stating what exceptions are thrown and when :)

[reply]
      If the DBI module threw useful exceptions when things went wrong, I would no longer have to sit there checking the return on every little operation to make sure things went ok. I could wrap my entire atomic operation in an eval {}, catch any exceptions I found relevant and re-start the entire operation or provide *useful* input to the user if necessary.
      Strangely enough you can do that. It's just a matter of reading through the documentation (1.30 here, 1.19 here).

      You can use the RaiseError, PrintError (and on later DBI versions) HandleError database handles to pull this off. If you download Tim Bunce's Advanced Perl DBI slides there is more information.

      Hope this helps...

      gav^

[reply]

In Section Seekers of Perl Wisdom