"put try/catch blocks around any "complicated" destructors, silently absorbing any exceptions that might occur. The rationale simply being – that, since you are dying anyway, nobody really cares about you anymore."
What an absolutely backwards, ignorant and absurd thing to do. Your assumption that nobody cares is equally as asinine.
If your destruction routines are that "complicated", fix them! If you're wrapping the destructor of someone else's code, DON'T hide information they may relay. You have no idea what someone is doing in there. What if it's designed to reset system components because if they don't get reset, the system may be damaged permanently after program restart? Yes, I have destructors that do these things.
"It might cause memory leaks but the bottom line is that the thing keeps going."
Wow. "Let's consume memory needlessly and permanently even though it's no longer needed or in use. Letting the program continue is more important than the stability of the system as a whole!".
Dumbfounding.
| [reply] |
Yeah, memory leaks is one of the worst class of bugs. If they happen more if the system is busier, this is even worse.
If, for example, your webserver code leaks memory with every page visited, everything is fine while you don't have much visitors. The first time a news article links to your site everything will halt and catch fire...
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
| [reply]
[d/l] |
I find this hilarious.
But then I'm the guy who put use warnings FATAL => 'all'; in my production code and shipped it to end users. Highly discouraged even by P5P.
Did it die on irrelevant warnings? Yeah, sure, in test it did. When it was wrong, I put no warnings 'foo'; # I'm expecting a foo warning here, it's fine in a tight block around the not-really-offending code, providing documentation about the code. But I got far more relevant exceptions (also in test) that allowed me to fix bugs before it shipped. And I got very very few, if any, exceptions in production because the QA team couldn't ignore the problems, they had to tell me about them, and thus they had a harder time escaping to clients.
Even now, the code I've inherited has so many try/catch blocks where exceptions are silently dropped that it makes it hard to test and hard to diagnose errors. I'm slowly reforming the code to get rid of those, so that I end up with code that's robust instead of accidentally working.
| [reply]
[d/l]
[select] |
| [reply] |