Comment by anonzzzies

For people who don't know how PHP works but do know Node, the Node example is really not at all similar. The result is similar but far worse; in PHP die() only makes that request die; in Node, it just exits the entire node server which could be doing other stuff. process.exit() is probably never a good thing while we see die() used, still, for 'security'. Not saying it's a great idea, but it's better than not having it in those cases; for instance;

      if (!$user->active) {
         <p>Fob off!</p>
         die() 
      } 
      <p>Passcode to the world: <?php echo $world->pasccode; ?></p>

We encounter many cases where people forget these and so information gets accessed that should not be. Of course, this is just a unhandled cases is evil and they are:

      if ($user->active) {
         <p>Passcode to the world: <?php echo $world->pasccode; ?></p>
      } else {
         <p>Fob off!</p>
      }

but in the wild (at many banks :), we encounter very many of the first case and often without the 'die' so a security issue. Our analysis tools catch all IF cases that don't handle all cases (which we see as an anti pattern, just like it's forced on a switch); alerting that this if has no else for the rest of the program to run makes people think and actually change their code. I rather see;

      if ($user->blah) { 
         setSomething($user); 
      } else {
         info("user not bla, not setting something");
      }
      # the rest

than what happens in 99% of code;

      if ($user->blah) { 
         setSomething($user); 
      } 
      # the rest

because the next maintainer might add something to the setSomething that will make the # the rest sensitive, save, commit, deploy and we notice it when it hits the news of 64m records stolen or whatever. In the first case, it alerts the maintainer etc to the fact there is more and they have to think about it. There are better ways to handle it of course, but I'm just saying what we see in the wild a lot and we are only hired to fix the immediate issues, not long term, so long term refactoring is never a part. We do advice different patterns but no-one ever listens; our clients are mostly repeat clients from the past 3 decades.