5 ms·

Those defensive measures you describe are the kind of hacks that introduce more and more complexity. Defensive programming is not fixing bugs with more feature

Those defensive measures you describe are the kind of hacks that introduce more and more complexity. Defensive programming is not fixing bugs with more features, quite the opposite: it is failing hard when a condition does not hold.

johnmaguire2013 7y ago
Yeah... The whole try/except "in case it throws" without an understanding of IF it should and WHY it might is a huge anti-pattern that creates more bugs down the line than it may potentially solve in the short-term. If it shouldn't throw, don't try to catch... That is an unexpected failure that needs to be understood.
- Joe-Z 7y ago
  I get so irritated whenever this is brought up as an "additional security measure". Like, guys, we just found the source of the bug and put in some code to fix it. If it fails again it shows we haven't understood it completely and should take another look. Not just throw in a random try-catch where the outcome is that if it fails again it's just that some string won't be rendered in the application anymore or whatever. Could take months before anyone notices and we learn that something basic has been broken all along. Thank you for standing up for confident programming! (We could make this a new term if we wanted to :D) EDIT: Wait, maybe there's a better term than confident programming already... I would appreciate some input if someone sees this.
  - johnmaguire2013 7y ago
    Wikipedia seems to call it "offensive programming": https://en.m.wikipedia.org/wiki/Defensive_programming https://en.m.wikipedia.org/wiki/Defensive_programming
  - shkkmo 7y ago
    There is a third route. You can add a try catch and then throw a more detailed exception (or otherwise automatically surface the issue while not degrading the user experience) showing the context of what failed, then fo attempt to fix a poorly understood bug for which you may have an incomplete set of reproduction circumstances for. The best solution is, as always, context and resource dependant.
- organsnyder 7y ago
  When I was interning at IBM (~15 years ago now), I saw a bug report closed with "added catch for NullPointerException" as the solution. Something tells me that developer didn't really dig to the bottom of the issue...
- ufmace 7y ago
  Well it depends on where. For ex: If a request handler in your web server is throwing an exception, it's not a good design for the whole server to go down because you thought it was a bad pattern to catch any exception that handling one request might throw. The whole request should fail, return a 500 to the client, and log exception details for later examination, but shouldn't be allowed to disrupt the rest of the server.
  - rocqua 7y ago
    Thing is, request handlers cross a boundary. Thus, you really should expect them to get malformed input. This means wrapping it in a try catch because 'input might be bad' is a pretty sane thing to do. At the same time, you really should try to validate inputs. The idea being that most exceptions caught should be of the form 'Input was invalid'. Rather than 'function crashed'.
    - ufmace 7y ago
      Well the parent seems to argue for at least only a very specific and limited catch. Perhaps the most common error is, say, invalid JSON. You wouldn't want to catch only the exception for that though. Maybe that's the most common, but who knows what other kind of subtle bugs might be in there. And the rule of thumb is that the web server process should never go down, no matter what kind of weird data you throw at it. That makes that indeed a case of catch everything, log it, and then move on to handle the next request.
      - johnmaguire2013 7y ago
        Sorry, I probably wasn't very clear - I'm not arguing that a try/except MUST be very targeted. > without an understanding of IF it should and WHY it might rocqua explains it best - the API handler is an "input" to the overall system. That input may be "invalid" in that it fails to handle its own errors. In that case, you should catch a general exception rather than crashing. In this case, you know that it might raise an error, why it might raise an error, and that it's OK to ignore (well, log/alert/whatever.) The situation I was responding to is very different - it's basically suggesting rather understand what the API you're invoking may be trying to tell you, just try/catch anything it throws and ignore it if you didn't expect it.
Dylan16807 7y ago
> Those defensive measures you describe are the kind of hacks that introduce more and more complexity. On the other hand, a system where damage is prevented in some ways and assumed not to happen in others is already an overly complex construction of interacting systems. Switching to an invulnerability flag could simplify the system.

johnmaguire2013 7y ago

Yeah... The whole try/except "in case it throws" without an understanding of IF it should and WHY it might is a huge anti-pattern that creates more bugs down the line than it may potentially solve in the short-term. If it shouldn't throw, don't try to catch... That is an unexpected failure that needs to be understood.

Joe-Z 7y ago
I get so irritated whenever this is brought up as an "additional security measure". Like, guys, we just found the source of the bug and put in some code to fix it. If it fails again it shows we haven't understood it completely and should take another look. Not just throw in a random try-catch where the outcome is that if it fails again it's just that some string won't be rendered in the application anymore or whatever. Could take months before anyone notices and we learn that something basic has been broken all along. Thank you for standing up for confident programming! (We could make this a new term if we wanted to :D) EDIT: Wait, maybe there's a better term than confident programming already... I would appreciate some input if someone sees this.
- johnmaguire2013 7y ago
  Wikipedia seems to call it "offensive programming": https://en.m.wikipedia.org/wiki/Defensive_programming https://en.m.wikipedia.org/wiki/Defensive_programming
- shkkmo 7y ago
  There is a third route. You can add a try catch and then throw a more detailed exception (or otherwise automatically surface the issue while not degrading the user experience) showing the context of what failed, then fo attempt to fix a poorly understood bug for which you may have an incomplete set of reproduction circumstances for. The best solution is, as always, context and resource dependant.
organsnyder 7y ago
When I was interning at IBM (~15 years ago now), I saw a bug report closed with "added catch for NullPointerException" as the solution. Something tells me that developer didn't really dig to the bottom of the issue...
ufmace 7y ago
Well it depends on where. For ex: If a request handler in your web server is throwing an exception, it's not a good design for the whole server to go down because you thought it was a bad pattern to catch any exception that handling one request might throw. The whole request should fail, return a 500 to the client, and log exception details for later examination, but shouldn't be allowed to disrupt the rest of the server.
- rocqua 7y ago
  Thing is, request handlers cross a boundary. Thus, you really should expect them to get malformed input. This means wrapping it in a try catch because 'input might be bad' is a pretty sane thing to do. At the same time, you really should try to validate inputs. The idea being that most exceptions caught should be of the form 'Input was invalid'. Rather than 'function crashed'.
  - ufmace 7y ago
    Well the parent seems to argue for at least only a very specific and limited catch. Perhaps the most common error is, say, invalid JSON. You wouldn't want to catch only the exception for that though. Maybe that's the most common, but who knows what other kind of subtle bugs might be in there. And the rule of thumb is that the web server process should never go down, no matter what kind of weird data you throw at it. That makes that indeed a case of catch everything, log it, and then move on to handle the next request.
    - johnmaguire2013 7y ago
      Sorry, I probably wasn't very clear - I'm not arguing that a try/except MUST be very targeted. > without an understanding of IF it should and WHY it might rocqua explains it best - the API handler is an "input" to the overall system. That input may be "invalid" in that it fails to handle its own errors. In that case, you should catch a general exception rather than crashing. In this case, you know that it might raise an error, why it might raise an error, and that it's OK to ignore (well, log/alert/whatever.) The situation I was responding to is very different - it's basically suggesting rather understand what the API you're invoking may be trying to tell you, just try/catch anything it throws and ignore it if you didn't expect it.

Dylan16807 7y ago

> Those defensive measures you describe are the kind of hacks that introduce more and more complexity. On the other hand, a system where damage is prevented in some ways and assumed not to happen in others is already an overly complex construction of interacting systems. Switching to an invulnerability flag could simplify the system.