|
|
|
| Syntactic Confectionery Delight | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
For your private code you should use die. To quote the Pragmatic Programmers, "Crash Early: A dead program normally does a lot less damage than a crippled one." If you are writing OO code, consider using Carp.pm and croak() or confess() so that the programmer gets a better idea of what went wrong (stack trace, etc).
For your public code you should also die. Although in some cases you may want to wrap that in some sort of eval to provide services to your users similar to the way CGI can be asked to print errors to the browser and DBI will not crash a program because of a SQL error (although maybe it should). If someone does not want their program to die as a result of misusing an API, they can wrap their code in an eval. Yes, you could return a false or some other error string, but then I have to write each call to your module as $foo->bar() or something; or as $foo->bar(); if $foo->err { something; }. In any case it's going to take just as long to track errors whether you die or try to handle the failure. But why make work for the script(er)? If the programmer absolutely cannot handle a failure they can catch it using $SIG{__DIE__}, I believe (having never felt the need to try this myself, I rely only on what I read at 'perldoc perlvar'). In reply to Re: What Are The Rules For Subs And Modules When Fed Wrong Input
by ichimunki
|
|