Re^5: why did i die?

[BrowserUk]

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.)

[markov]

If the eval'd code already catches these errors, then it is not the responsibility on "my level eval" anymore that it is treated correctly. I only want to be able to handle accidents which happen unhandled.

There are many frameworks which offer many levels of messages, like syslog. When you maintain larger applications, you often route messages based on the seriousness (level) of the message. For instance, you make panics and alerts very visible, and ignore warnings. So: many people agree that Perl's one-level-fits-all concept is too limited.

You: really don't think there is any sensible way for a generic logging module to categorise the seriousness of exceptions thrown by unknown code.
That's not what I am looking for: I only want to be able to separate Perl's internal die's from user-program die's. Other problems are solved (or unsolved) in other ways.

[BrowserUk]

When you maintain larger applications, you often route messages based on the seriousness (level) of the message. For instance, you make panics and alerts very visible, and ignore warnings.

I don't disagree with that, but the categorisation should be done but the author of the code that can generate the exceptions; not after-the-fact by a third party logging package that has no knowledge of the code.

That's like giving the telephonist responsibility for deciding who gets an emergency response, based upon the their interpretation of the description provided by a 5 y/o child. "Mommy's asleep and won't wake up!"

[markov]

Totally true. However... it is not in the design of our beautiful language. There is even no guideline about what is preferred. So, the only way left is to do the best you can... and I can do a little better I hope. At least, I hope to be able to separate the three causes for filling $@.

It's not that I am not aware how bad the situation is, just that I try to make the best of it. And yes, the telephonist will decide urgency based on the 5yr old's description.