Re^2: error catching

However, mostly people leave the DBI on it's default settings, which carp() errors before you ever get to the "or" part of your statement.

While I don't know what people normally do, the DBI default is for some unexplicable reason to not do that: (from the docs):

"RaiseError" (boolean, inherited)
The "RaiseError" attribute can be used to force errors to raise exceptions rather than simply return error codes in the normal way. It is "off" by default. -snip-

Update: just to be clear: the parent node's comments about $! and $dbi->errstr are correct, it's just that the default DBI setting is to use those, and not throw exceptions. If you want to automatically get an exception on a database/SQL error (and I suggest you should), you need to use the RaiseError option on the DBI->connect call.

update2: jettero is correct in his correction, but we both seem to agree that you should use RaiseError to catch any further errors. The chances of anything unexpected going wrong later without notice are a lot higher if you don't.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re^2: error catching

Replies are listed 'Best First'.
Re^3: error catching by jettero (Monsignor) on Dec 20, 2006 at 00:55 UTC
While I don't know what people normally do, the DBI default is for some unexplicable reason to not do that: (from the docs): False. I was reading just above where you were reading. By default, "DBI->connect" sets "PrintError" "on" I agree that you still have to `die()` if your `$sth` fails, which I thought I had implied, but it will (by default) at least print the error on its own. The RaiseError is different and actually `croak()`s instead of just `carp()`ing. Update, because it happens to be on my other monitor anyway, here's the relevant source [the comments are mine]: `Carp::croak($msg) if $attr->{RaiseError}; # not default Carp::carp ($msg) if $attr->{PrintError}; # default` [download] -Paul	[reply] [d/l] [select]
Re^4: error catching by Joost (Canon) on Dec 20, 2006 at 01:02 UTC
You're right. I completely forgot about the difference between carp and croak, mainly because I personally only use croak (and also because I tend to think that exceptions are much more useful in this particular case). "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^5: error catching by jettero (Monsignor) on Dec 20, 2006 at 01:05 UTC
I totally agree that raise error should be on by default... I'd rather have an `eval { $sth->execute }; if ($@) { ... }` where I don't want it to just die, ya know? But hey, I could just turn it on I suppose. I never remember is the main problem with that plan. -Paul	[reply] [d/l]
Re^3: error catching by diotalevi (Canon) on Dec 20, 2006 at 00:59 UTC
RaiseError doesn't work for the initial ->connect statement. You need to check that one manually. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^4: error catching by runrig (Abbot) on Dec 20, 2006 at 01:04 UTC
Yes, it does. Since 0.91.	[reply]
Re^5: error catching by diotalevi (Canon) on Dec 20, 2006 at 01:06 UTC
Oh. That hasn't been true in any DBI I've knowingly used. Maybe the feature just didn't work for several years. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^4: error catching by Joost (Canon) on Dec 20, 2006 at 01:05 UTC
I meant to say "use RaiseError as an option to the connect call", not as the check for the connect call. Anyway, don't most calls to an unconnected $dbh cause an exception? "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^5: error catching by diotalevi (Canon) on Dec 20, 2006 at 01:08 UTC
Yes. A failed ->connect call returns undef so there's no object that a method can be called upon. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]