App fails, Check logs...No error logged. Check source code and debug....
And then you see following piece of code....

//Code to hit an API
}catch(Exception ex){
/*DO NOTHING. Not even log stack trace*/

  • 3
    I inherited a codebase that did a very similar thing. It wasn't quite as bad but what it was doing was catching all errors no matter what they were and turning them into generic 500 server errors with no message and nothing logged. So you could tell something was breaking, but you couldn't tell what or why.
  • 1
    In my case, I had a logger info in catch saying "api call done" or similar. I blindly assumed it was a 2xx before we saw a mismatch in the log count.

    At which point, we realized we had been duped
  • 2
    At least has a catch.. haha
  • 0
    It's not that bad, as it gets. There are scenarios where it can be right approach. First example is char array to string decoding, potentially throwing exception for invalid encoding.
    Another example is having connection error handling in upper layers, or aspects, and logging handled in lower layers, or aspects. I do this quite often.
    One more example - having default value assigned to variable and reading from configuration. You can have FileNotFoundException or NumberFormatException, which are moot. You just keep the defaults, there is no need to explicitly log the problem.

    There is approach in which all logs must be handled, either by safe checks, or just changing the log level when it's acceptable. I'm a fan of this approach :)
  • 0
    @mt3o They're hardly moot if you want to give your users any kind of information as to why their config failed to load.

    File not found is very different from illegal number formatting.

    Relying on exceptions in non-exceptional scenarios is just bad form. Exceptions are not meant give you a lazy way to avoid properly handling error conditions.
  • 1
    @devios1 my app has about 30 instances running, my team is the only one touching the cfg, logs and other administrative stuff. That's why we couldn't care less. :)
    It all depends on scenarios you are handling, there is no such thing as one-approach-fits-all-cases.
  • 2
    That’s so annoying!
Add Comment