die-ing within functions

[Stevens]

Hi,

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare return
statement? What about displaying error messages within perl functions, is
this frowned (as it tends to be in unix systems programming) upon?

Cheers,

Stevens

 

[Matija Papec]

X-Ftn-To: Stevens

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare return
statement? What about displaying error messages within perl functions, is

IMO, dying is fine as you can always catch these with eval { };

 

[Toni Erdmann]

Hi,

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare return
statement? What about displaying error messages within perl functions, is
this frowned (as it tends to be in unix systems programming) upon?

You should perfer using 'return undef;' if possible to indicate an
error. If, however you find a severe error during operation within
a function, it's better to use 'die' instead of 'exit'.

sub function
{
...
die "Error";
}

can be handled by the calling code:

eval { function() };
if ( $@ ) {
warn "function() caused an exception: $@";
}

which can't be done using 'exit' in 'function()'

If there's no 'eval{}' around the call, then it simply 'die's.

I always try to avoid 'print' in subroutines and try to
'return undef;' instead.

Toni

 

[Sherm Pendley]

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare
return statement?

So long as it's documented as doing so, I don't see why it would be all that
bad. Even if the default of die()ing isn't appropriate for some cases, it's
not a fatal flaw; it can always be trapped by an eval().

What about displaying error messages within perl functions, is
this frowned (as it tends to be in unix systems programming) upon?

I'd use warnings::warnif(), so that the user of the function could disable
the warnings as he sees fit, with "no warnings 'MyPackage';". (This is one
way the 'warnings' pragmatic module is much, much, much better than the
simplistic '-w' switch...)

Another option is to place the warning message in a scalar, and then call
'warnings::warnif($error_message);'. This would allow users of your
function to disable the standard behavior, and display the warning in a way
that's more appropriate for their app, for example by popping up a GUI
dialog.

sherm--

 

[Anno Siegel]

Hi,

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare return
statement? What about displaying error messages within perl functions, is
this frowned (as it tends to be in unix systems programming) upon?

Unconditionally dying in library routines is bad style anywhere. The only
place for it is bug catching (that is, dying under conditions that cannot
happen when the program is correct).

Now one could argue that Perl has eval(), and hence dying is never truly
unconditional, but that solution should be reserved for cases where a
function *does* die inappropriately. If the user has to undo things a
routine has done, the routine is doing (and assuming) too much, that goes
for dying as for other services.

The pragmatic "warnings" module offers a solution in that it allows the
user to control the behavior (ignore, warn, die). However, I hesitate
to recommend it unconditionally. The control it gives is somewhat
flakey, and a warning can consume considerable time even if it is
turned off. Both problems have to do with the fact that "warnings"
uses "Carp" to do the error attribution.

However, the spirit of "warnings" is the way it should be. It's the
end users who ought to control behavior under error conditions (with
reasonable defaults, so they don't *have* to). Only they know what the
consequences are if something goes wrong.

Anno

 

[Ala Qumsieh]

Hi,

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare

return

IMHO, there is nothing wrong with die()ing [sic] within a function if it
doesn't make sense for the program to continue running afterwards.

statement? What about displaying error messages within perl functions, is
this frowned (as it tends to be in unix systems programming) upon?

It really depends on your style. I don't think perlstyle says anything about
that. I certainly don't mind spitting out error/warning messages from within
functions since I generally think of functions as OO methods. So each
function is supposed to do one thing only, and if it fails, then it is its
responsibility to report that.

--Ala

 

[ctcgag]

Hi,

I'm looking for some advice on programming style ... is is considered bad
practice to die within your own functions as opposed to using a bare
return statement?

If death is the appropriate response, then death is the appropriate
response.

If returning an undef or an empty list is reasonable for the function to do
under some non-error conditions, then it would be very bad form to have it
simply do that under error conditions as well.

It all depends on what the function will be used for.

What about displaying error messages within perl
functions, is this frowned (as it tends to be in unix systems
programming) upon?

Do you anticipate your code being ported to another (human) language
without needing a major re-write for other reasons? If so, then you may
want to abstract the error messages into one place. Otherwise, it's
probably just a pain in the butt to do so.

Xho

 

[Sherm Pendley]

Now one could argue that Perl has eval(), and hence dying is never truly
unconditional

That's one down... when's Larry going to get to work on taxes? ;-)

sherm--

 

[Tad McClellan]

That's one down... when's Larry going to get to work on taxes? ;-)

We should just be thankful that we don't get all the government we pay for.

 

[Chris Mattern]

That's one down... when's Larry going to get to work on taxes? ;-)

That's been in there from the beginning--since perl is free, you
never pay any taxes on it!
--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"