4 ms·

I do think your example should be as simple as: try { _legacyCandidateRepo.SaveWithIncrementalBackoff(candidate); } catch (Exception exc) { HandleExcep

I do think your example should be as simple as: try { _legacyCandidateRepo.SaveWithIncrementalBackoff(candidate); } catch (Exception exc) { HandleException(exc); } This way, the code is extremely readable, especially if you can easily "Go to definition" in a service, and the file this try-catch isn't 200 lines long. Also, try-catch is generally an anti-pattern. It should only occur when you genuinely have no way whatsoever to prevent the exception, as such, it will be pretty rare. Again, it does happen, for example we have an unstable legacy db we hit that we don't have access to, but it should be fixed asap. Tbh, this is a constant argument between our juniors and I. They want to write 15 line methods, but I have found that they don't want to debug it. It's constantly them building quickly on top of my code and then me having to fix theirs because they get frustrated debugging their own code.

dj_mc_merlin 6y ago
Whatever is inside the catch block is by definition the exception handler, so I find the extra function definition to not bring much value. It also doesn't annoy me too much since I can just go to definition, but if it's only 3-4 lines long I would rather have it in the block itself so I can read it at a glance. > try-catch is generally an anti-pattern. Exceptions are a very useful part of the language if you use them right (to divert code flow in predictable ways in unpredictable scenarios), although I agree it can be easy to go wrong. Regarding your juniors, that seems more of a problem of skill or determination than anything. Debugging in Java is relaxing, it has stack traces, a debugger, a nice IDE, no segfaults.. a 15 line function should not be an obstacle. I would even prefer to have more of the code on the screen sometimes so I can get the implementation details in my head .

dj_mc_merlin 6y ago

Whatever is inside the catch block is by definition the exception handler, so I find the extra function definition to not bring much value. It also doesn't annoy me too much since I can just go to definition, but if it's only 3-4 lines long I would rather have it in the block itself so I can read it at a glance. > try-catch is generally an anti-pattern. Exceptions are a very useful part of the language if you use them right (to divert code flow in predictable ways in unpredictable scenarios), although I agree it can be easy to go wrong. Regarding your juniors, that seems more of a problem of skill or determination than anything. Debugging in Java is relaxing, it has stack traces, a debugger, a nice IDE, no segfaults.. a 15 line function should not be an obstacle. I would even prefer to have more of the code on the screen sometimes so I can get the implementation details in my head .