For this last idea, I'd pass the whole $ERR hashref to the fatal_error function. Up to the function to decide, based on configuration variables (possibly, a --debug command-line option), whether to print something on STDERR, send a email or whatever.
Besides that, have you considered using the exception handling mechanism? Run the code that can cause an error within an eval {} construct. The code in question will simply die should anything go amiss, with a usefull error message or error code. After the eval, you just test whether $@ is true and handle the error depending on its value. e.g.
eval { # format_output or get_user may die $formatted_users = format_output(get_users($fh)); } if ( $@ ) { # test the value of $@ to know what's been going on. die $@ }
This approach let you separate in distinct blocs the actual code (eval { ... }) and the error handling (if ( $@ ) { ... }).
UPDATE: of course, you still need to come up with a convention about the contents and format of $@.
UPDATE: When testing the value of $@, you can of course choose not to die, but send an email, come up with a reasonable default for the value that failed just to be created, or do whatever you care to handle the error. If you can't figure out what happened by testing on $@, then die $@ so that the error is caught at an upper level, where it might become fatal.
HTH
--bwana147
In reply to Re: style for returning errors from subroutines
by bwana147
in thread style for returning errors from subroutines
by Boldra
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |