Is it better to croak() or to die() when something bad happens in Perl?
Asked Answered
C

6

27

perlcritic complaints that the following code, some boilerplate DBI stuff that works perfectly fine, should croak instead of die:

# Connect to database
my $db_handle = DBI->connect( $url, $user, $password ) or die $DBI::errstr;

All this, while die seems to work fine for me.

I would think for a samurai Perl warrior, croak is less honorable than actually die when things go awry. Jokes apart

Why should I croak instead of die?

What are the consequences of not heeding perlcritic's advice?

Coronado answered 11/11, 2010 at 16:2 Comment(0)
A
41

From http://www.perlmonks.org/?node_id=685452

You use die when the error is something you or your code didn't do right. You use croak when it's something your caller isn't doing right. die "error: $!" indicates the error is on the line where the error occured. croak "error: $!" indicates the error is on the line where the caller called your code.

In this case, the error (connection error to DB) has nothing to do with the caller and everything to do with the line making the connection, so I would use die.

Armory answered 11/11, 2010 at 16:7 Comment(1)
@Adrin What if the connection info came from the caller? Would you still use die()?Muezzin
J
9

I usually use the following:

  • die "string" for fatal messages you want to directly communicate to the user. I mostly do this in scripts.
  • die $object for full blown exception objects, although most exception classes will have throw method doing that for you. This is for when your caller should be able to tell what kind of error you throw, and maybe even extract information out of it. If you're using Moose, check out Throwable and Throwable-X
  • croak "message" like Adrian said is for when your user has done something wrong, and you want to report the error at whatever called your code. Functions and API level methods are usual cases for this.
  • confess "message" for library errors where I don't see the usefulness of an exception yet. These are usually runtime errors you assume to be a mistake, rather than an exceptional condition. It can make sense to use exceptions for these, especially if you have a large project that uses exceptions already. But it's a good, nice and easy way to get a stacktrace with the error.
Jennie answered 11/11, 2010 at 16:50 Comment(0)
H
4

If we called the die and croak outside the function there is no difference between these functions.

We can only find difference when we call die and croak within any other function.

croak will gives information about the caller such as function name and line number..etc. die will give error and gives the line number where the error has occured.

Hygrometric answered 13/7, 2016 at 12:8 Comment(0)
P
3

It's not necessarily wrong to use die() but croak() gives you or your user a lot more information about what went wrong. There's also variables that can be set in the Carp namespace that can change this output to get more or less information.

It's equivalent to die() but with more information and control.

Parapsychology answered 11/11, 2010 at 16:6 Comment(0)
L
0

Still. This example may want to use croak if the connection parameters came directly from the inputs to the function as others pointed out.

If you write a test for yourself that triggers the exception then you will be your own client and appreciate which is better.

If it is very hard to test error condition it may be a case for die over croak. But any parameter validating errors should use croak.

Liatris answered 19/5, 2012 at 13:26 Comment(0)
T
0

The Carp routines are useful in your own modules because they act like die() or warn(), but with a message which is more likely to be useful to a user of your module.

https://perldoc.perl.org/Carp

Tilda answered 13/1, 2021 at 16:54 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.