This is probably bad style, because it detects the error it a low level (where this routine is hidden away), but it doesn't allow the error to handled at a high level-- it throws an error itself immediately. The issue here is that most of the time I do want to throw this error. So I want to be able to handle the error at a high level, but for it happen automatically if I want to.sub is_pg_date_error { my $key = shift; my $value = param($key); if ($DBI::errstr =~ m/Bad date external representation '$value'/o) + { error(title=>'Inproper date format', msg=>"There is a problem with $key field. Please return an +d format it in the format YYYY-MM-DD and confirm that it is a valid da +te.") } }
Looking at how CGI.pm and DBI.pm deal with errors, they both have similiar approaches which are inline with the "Practice of Programming" principles-- when there is an error, they populate some global routines in their package with the relevent errors. You can choose to do something with these errors or just ignore them.
So, when developing custom modules, would recommend the same error handling scheme in general? That is, when there is an error, instead of dealing with directly or returning it to user, stick it into a package global which the user can manipulate on their own? If not that, what other insights on the art of error handling do you have? Thanks!
-mark
In reply to The art of error handling by markjugg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |