Can you instruct the coders that expected die messages should be prefixed (or contain) some specific piece of text. Then you only need check for that.
Perhaps, tell them that deliberate exits should be done with just die(); and look for the "Died at" text.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
I tried to keep the question easy, simply stating that it should be a generic solution. The application is more complex (of course).
Log::Report is a powerful logging/exception/translation framework. It provides functions like error(), trace() and alert(), and puts them to syslog, log files, log4perl, etc. It also provides a try(). Now, the try (=eval) can catch an Log::Report::Exception object, but also texts produced by dies and croaks originating from modules which have not been implemented via the Log::Report framework. I have no control over the error message produced in CPAN modules.
Now, the try() attempts to translate these error texts into exception objects. When this exception is send to syslog (or log4perl, or ...) I want to be able to send it with the right error level. For parser errors and division by zero errors (and friends), I want to flag a more serious error-level than for "expected" errors.
| [reply] |
For parser errors and division by zero errors (and friends), I want to flag a more serious error-level than for "expected" errors.
I think you are on a hiding to nothing trying to interpret the meaning of exceptions from unknown code.
For example: What if the code already traps a division by zero error, but then re-throws it (via die) but with some other text that makes sense in the context of that particular module? (Say: "Average calculation failed: zero datapoints supplied." or similar.)
How are you going to classify that? Is it one of your "more serious" errors or an "expected" error?
I really don't think there is any sensible way for a generic logging module to categorise the seriousness of exceptions thrown by unknown code.
And even if there was, I'd suggest that it shouldn't anyway. A logging module should log; not interpret.
(Probably not what you want to hear, but its just an opinion. Then again, I reject the whole Test::* suit of modules primarily because they mess with my output; and thus get between me and my quickest route to solving bugs; all in the name of producing pretty printed garbage statistics.)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
The "expected" die() messages are not under my control. :) So keep a table of messages which are under your control?
See what diagnostics does (perldiag)
| [reply] |