3 ms·

Gotta love reading a new to you codebase and seeing a bunch of catch (Exception ex) { }; littered throughout. Fixed the bug boss, close that ticket!

marklubi 1y ago
Totally agree with finding the source of the bug (there are some that I've spent weeks tracking down, there are millions of people that have my fixed code on their devices). If you've going to catch an error with a noop, there better be a comment explaining why you're not doing anything. It's not often, but sometimes, failing gracefully is just swallowing the error and moving on.
- xboxnolifes 1y ago
  At minimum, the error should be logged somewhere, and not just vanished. At least you get to know how frequently it occurs if/when that becomes meaningful to you.
  - vel0city 1y ago
    Exactly this. Log it, maybe at some really verbose log level, but please let me know it is hitting this point and a little bit of information of what the exception was. Also, only do it for exceptions you think might actually hit there and you're OK with quietly squashing. Otherwise, please let something else try and handle it.
  - marklubi 1y ago
    In an app, if you have a string of network requests to your own services, there's no particular point in logging multiple (or any) 'no internet connection' errors. They won't make it to you, and having those doesn't provide much value. That's an end user problem. I have plenty of monitors to ensure my services are available (four-nines uptime for almost a decade). Internet unavailable errors are useless to log.
scrame 1y ago
this completely happened to me, but with a comment: // this never happens ... guess what happened? /happenings
- layer8 1y ago
  In every project I have an unchecked CantPossiblyHappenException type (usually with a better name ;)) that is thrown in such cases. This documents that the developer thought this condition can’t occur, while still escalating it should it nevertheless occur.
atoav 1y ago
Handling exceptions is interesting because in my experience a lot of it boils down to a social dimension: * if the input data field for a telephone number contains a country name do you communicate that error back to the source, if yes how and how often (assuming your source isn't a life user bit a bureaucratic institution) * if there is an error that really shouldn't happen, how will you notice? You probably don't have all the logs scrolling on 100 displays to watch for the red. So maybe send emails? But if you send emails about pointless stuff people will start to ignore them
lapetitejort 1y ago
I struggled with this recently. Someone was trying to patch up an error and force the program to continue. I asked him what was causing the error and he could only respond with how they were trying to patch it. I got so frustrated that I took on the error myself and fixed it with two lines of code. I think the problem is that some people think errors are supposed to happen. Just a cost of doing business. They can't be fixed, only mitigated.
tshaddox 1y ago
Sometimes you're stuck using some API that throws exceptions for expected (i.e. non-exceptional) errors, and you really do want to do nothing additional when those expected errors occur.
- devman0 1y ago
  This is, in theory, the difference between checked and unchecked exceptions in languages that support such distinctions. Checked exceptions are basically part of the control flow and the API contract used for things that can happen but are not necessary programmer errors (IO Exceptions being the classic example). Whereas unchecked exceptions are supposed to be used for programming errors (think Illegal Arguments, Null Pointer, Array Index Out of Bounds). Unchecked also usually cover other fatal conditions like stack overflow or OOM. Checked, handle with care, Unchecked, let the stack unwind and fail fast.
- vel0city 1y ago
  Sure, I agree. I'd still prefer you properly scope it to just those expected exceptions, maybe put in some kind of debug level log related to it. The above code grabs every kind of exception and silently squashes it into oblivion.
Groxx 1y ago
especially Exception. Ugh. Gotta love those interrupt-ignorers.
- layer8 1y ago
  Unfortunately, it’s somewhat of a lost cause unless you control all the code. Even some OJDBC drivers swallow interrupts. I had to resort to application-specific interrupt flags.
sidewndr46 1y ago
On Error Resume Next The single line that magically fixes all Visual Basic 6 applications bugs
- layer8 1y ago
  Bash does it even by default. ;)
eknkc 1y ago
Having a lint rule to disallow empty catch bodies has been a good practice for me. Sometimes you deliberately do it and even then I am forced to at least leave a `// ignore` there.
- vel0city 1y ago
  Absolutely, linter rules that expose such things are critical to fixing these things. And I add them to the PR linter to comment on PRs when I can to point out discussions about such things.

marklubi 1y ago

Totally agree with finding the source of the bug (there are some that I've spent weeks tracking down, there are millions of people that have my fixed code on their devices). If you've going to catch an error with a noop, there better be a comment explaining why you're not doing anything. It's not often, but sometimes, failing gracefully is just swallowing the error and moving on.

xboxnolifes 1y ago
At minimum, the error should be logged somewhere, and not just vanished. At least you get to know how frequently it occurs if/when that becomes meaningful to you.
- vel0city 1y ago
  Exactly this. Log it, maybe at some really verbose log level, but please let me know it is hitting this point and a little bit of information of what the exception was. Also, only do it for exceptions you think might actually hit there and you're OK with quietly squashing. Otherwise, please let something else try and handle it.
- marklubi 1y ago
  In an app, if you have a string of network requests to your own services, there's no particular point in logging multiple (or any) 'no internet connection' errors. They won't make it to you, and having those doesn't provide much value. That's an end user problem. I have plenty of monitors to ensure my services are available (four-nines uptime for almost a decade). Internet unavailable errors are useless to log.

scrame 1y ago

this completely happened to me, but with a comment: // this never happens ... guess what happened? /happenings

layer8 1y ago
In every project I have an unchecked CantPossiblyHappenException type (usually with a better name ;)) that is thrown in such cases. This documents that the developer thought this condition can’t occur, while still escalating it should it nevertheless occur.

atoav 1y ago

Handling exceptions is interesting because in my experience a lot of it boils down to a social dimension: * if the input data field for a telephone number contains a country name do you communicate that error back to the source, if yes how and how often (assuming your source isn't a life user bit a bureaucratic institution) * if there is an error that really shouldn't happen, how will you notice? You probably don't have all the logs scrolling on 100 displays to watch for the red. So maybe send emails? But if you send emails about pointless stuff people will start to ignore them

lapetitejort 1y ago

I struggled with this recently. Someone was trying to patch up an error and force the program to continue. I asked him what was causing the error and he could only respond with how they were trying to patch it. I got so frustrated that I took on the error myself and fixed it with two lines of code. I think the problem is that some people think errors are supposed to happen. Just a cost of doing business. They can't be fixed, only mitigated.

tshaddox 1y ago

Sometimes you're stuck using some API that throws exceptions for expected (i.e. non-exceptional) errors, and you really do want to do nothing additional when those expected errors occur.

devman0 1y ago
This is, in theory, the difference between checked and unchecked exceptions in languages that support such distinctions. Checked exceptions are basically part of the control flow and the API contract used for things that can happen but are not necessary programmer errors (IO Exceptions being the classic example). Whereas unchecked exceptions are supposed to be used for programming errors (think Illegal Arguments, Null Pointer, Array Index Out of Bounds). Unchecked also usually cover other fatal conditions like stack overflow or OOM. Checked, handle with care, Unchecked, let the stack unwind and fail fast.
vel0city 1y ago
Sure, I agree. I'd still prefer you properly scope it to just those expected exceptions, maybe put in some kind of debug level log related to it. The above code grabs every kind of exception and silently squashes it into oblivion.

Groxx 1y ago

especially Exception. Ugh. Gotta love those interrupt-ignorers.

layer8 1y ago
Unfortunately, it’s somewhat of a lost cause unless you control all the code. Even some OJDBC drivers swallow interrupts. I had to resort to application-specific interrupt flags.

sidewndr46 1y ago

On Error Resume Next The single line that magically fixes all Visual Basic 6 applications bugs

layer8 1y ago
Bash does it even by default. ;)

eknkc 1y ago

Having a lint rule to disallow empty catch bodies has been a good practice for me. Sometimes you deliberately do it and even then I am forced to at least leave a `// ignore` there.

vel0city 1y ago
Absolutely, linter rules that expose such things are critical to fixing these things. And I add them to the PR linter to comment on PRs when I can to point out discussions about such things.