Re: Carping about object destruction when errors are unprocessed?

If it were I, I'd make the Final Error Pass optional, and set it with either the 'debug' or 'verbose' option.

I personally think that there should be no un-caught/un-corrected errors in anything that goes to production. If it was important enough to kvetch about, it is important enough to fix. But, I also realize that there are some anomalous conditions that are useful to know about, but do not require immediate programatic action to address.

What you don't want to do is throw an error in production that, while it doesn't effect the final outcome of the calculation, does leave the User with a feeling that not everything is right with the world. Thus the optionality of the final error-pass.

----
I Go Back to Sleep, Now.

OGB

Comment on Re: Carping about object destruction when errors are unprocessed?

Replies are listed 'Best First'.
Re^2: Carping about object destruction when errors are unprocessed? by radiantmatrix (Parson) on Sep 05, 2006 at 18:42 UTC
Hm, making it optional (but default on) is a reasonable thought. Two points I wanted to make clear, to make sure we're really on the same page: The proposal is just to warn, not to halt -- not sure if that satisfies your concern your comment about "throw{ing} an error in production that, while it doesn't effect the final outcome of the calculation, does leave the User with a feeling that not everything is right with the world." As I just finished writing in another reply, these errors are of the non-fatal variety. Sometimes, it's important to know about it (to, say, inform program logic), but not something that needs a "fix", per se. Yes, die and friends could be used for this as well, but there are some acceptable reasons why the design team chose this path. That said, I want to reiterate that supplying a 'verbose' option to control the "carp on DESTROY" function might not be a bad idea (thanks!), though a consuming module could always just override DESTROY if the warnings were inappropriate... <–radiant.matrix–> A collection of thoughts and links from the minds of geeks The Code that can be seen is not the true Code I haven't found a problem yet that can't be solved by a well-placed trebuchet	[reply]

Replies are listed 'Best First'.

Re^2: Carping about object destruction when errors are unprocessed?
by radiantmatrix (Parson) on Sep 05, 2006 at 18:42 UTC

Hm, making it optional (but default on) is a reasonable thought. Two points I wanted to make clear, to make sure we're really on the same page:

The proposal is just to warn, not to halt -- not sure if that satisfies your concern your comment about "throw{ing} an error in production that, while it doesn't effect the final outcome of the calculation, does leave the User with a feeling that not everything is right with the world."
As I just finished writing in another reply, these errors are of the non-fatal variety. Sometimes, it's important to know about it (to, say, inform program logic), but not something that needs a "fix", per se. Yes, die and friends could be used for this as well, but there are some acceptable reasons why the design team chose this path.

That said, I want to reiterate that supplying a 'verbose' option to control the "carp on DESTROY" function might not be a bad idea (thanks!), though a consuming module could always just override DESTROY if the warnings were inappropriate...

<–radiant.matrix–>
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

[reply]