Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: Debugging DESTROY calls in forking application

by Anonymous Monk
on Mar 11, 2020 at 00:08 UTC ( #11114110=note: print w/replies, xml ) Need Help??

in reply to Debugging DESTROY calls in forking application

This node falls below the community's threshold of quality. You may see it by logging in.
  • Comment on Re: Debugging DESTROY calls in forking application

Replies are listed 'Best First'.
Re^2: Debugging DESTROY calls in forking application
by stevieb (Canon) on Mar 11, 2020 at 00:51 UTC
    "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!".


      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";'
Re^2: Debugging DESTROY calls in forking application
by Tanktalus (Canon) on Mar 11, 2020 at 16:39 UTC

    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.

Re^2: Debugging DESTROY calls in forking application
by Your Mother (Archbishop) on Mar 11, 2020 at 17:24 UTC

    Just tagging this wisdom—memory leaks keep the thing going—for potential future collation.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11114110]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2021-05-17 04:17 GMT
Find Nodes?
    Voting Booth?
    Perl 7 will be out ...

    Results (153 votes). Check out past polls.