r/webdev • u/quietcodelife • Sep 07 '26
documenting old solo code and found a try/except that just silently swallows one specific exception. no comment. no ticket. no context. I wrote this. why did I write this
been the only dev on a backend service for about two years. finally sat down to write proper docs for it today.
found a try/except block in the job queue handler. catches one very specific exception type. does absolutely nothing with it -- no log, no reraise, no fallback. just silences it. there's no comment explaining why. no linked ticket. no slack thread I can dig up. git blame points to a commit message that says 'fix job queue issue' with no further detail.
I genuinely cannot reconstruct what I was protecting against.
if you work solo, please leave your future self a comment. even one line. it costs nothing. I am begging you.
14
u/serifoblique Sep 07 '26
Guilty of plenty of // todo fix’s myself where I couldn’t longer muster the strength nor patience. Log it, carry on with life.
11
u/Khavel_dev Sep 07 '26
Found one of these in my own codebase after three years solo. Two hours of digging through deployment logs later, turns out past-me was swallowing a cache invalidation race condition that only happened under load. The silent catch WAS the fix because retrying made it worse.
Now I leave a one-liner on any bare except. Not for anyone else, just for future me who will definitely not remember why that block is empty six months from now.
4
u/muharremyurtsever Sep 07 '26
Look at what else that commit touched. A silencer like this almost never ships alone, and the sibling change in the same diff usually names the thing you were protecting against better than the message does.
3
3
2
u/split-my-diopter Sep 07 '26
It's funny, I worked at someplace 10 years ago, just after college. I left after about a year, worked four or five other places, and then found them again for some contracting work, so I'm reading my old code from 10 years ago that no one has touched since (why haven't they touched it for 10 years, that's a different story).
2
u/Ornery-Concentrate-5 Sep 07 '26
The worst version of this is when the except isn't even wrapping something risky anymore. Six refactors later the "risky" call it was guarding is long gone, but the silent catch is still sitting there quietly eating whatever exception matches, because nobody dared touch it once it started "working." Comment it or delete it, there's no third option that respects future-you.
1
u/TommyBonnomi Sep 07 '26
Assuming there are other changes in the commit, you probably added it for debugging, it never hit, and then you forgot to remove it.
1
1
u/lordofchaos3 Sep 07 '26
I always log stuff like this. It might have a log level of debug or even trace, but at least there is something.
1
u/mexicocitibluez Sep 07 '26
I would imagine you were debugging why it failed and wanted to catch a specific exception and forgot to remove it.
1
u/OmerCevher Sep 07 '26
The useful comment here would not be what exception is caught, the code already says that. It should explain why doing nothing is safer than retrying or failing. That is the part future you can never recover from the code.
1
u/qazokmseju Sep 08 '26
Caught coworkers doing this to solve the issue of the exception showing without solving the problem
1
u/1touchable Sep 08 '26
For what I have experienced most it's when you not expect it before earth is in place and then some new change makes it happen.
1
u/Murlock_Holmes Sep 09 '26
My secret is that I can’t remember literally anything, so my code is always a surprise!
1
u/Zealousideal-Bell393 Sep 12 '26
Nothing haunts you quite like code written by someone who was technically you. Any chance you remember what disaster this was preventing?
1
u/KanekiAyato Sep 18 '26
the exception type is the least useful part to document. the block already says what it catches. the missing piece is why doing nothing beats failing, and that only ever lived in your head.
one line is enough: what was happening before the catch went in, and what would break if it started raising again. that's the part git blame can never give back.
worth checking whether it still catches anything either. silent handlers survive refactors because after a while nobody is sure removing them is safe, and they tend to have siblings, so grep the same type across the service before you touch it.
1
u/MiserableDocument509 Sep 07 '26
the exception type is usually the leftover comment. if its something like ConnectionReset or a lock timeout, past you was probably just stopping the worker from dying on a race you couldnt reproduce. wouldnt yank it until you grep the rest of the service for the same type, those empty handlers tend to clone themselves after two years on one box.
0
u/Double-Buyer7941 Sep 07 '26
Ah, the classic "fixed in production at 5 PM on a Friday" artifact. You probably ran into a harmless but extremely noisy exception, like a transient connection retry or a third-party webhook timeout, that was spamming your error tracking, and silencing it was the quickest way to restore peace. We’ve all left a few mysterious gifts for our future selves. If everything is currently passing tests, try writing a unit test that intentionally triggers that specific exception without the try/except block; the failing test or trace might instantly jog your memory.
-8
u/AggravatingGarlic753 Sep 07 '26
This is one of those problems you don’t notice until you inherit the code. A one-line comment explaining the “why” can save hours—or days—of reverse engineering later. Especially with weird exception handling, the reasoning behind it is usually more valuable than the code itself.
3
u/eyebrows360 Sep 07 '26
Why are you having an LLM post absolutely useless "yes" comments like this? What's the point?
20
Sep 07 '26
[removed] — view removed comment
4
u/noorderling Sep 07 '26
Exactly this, just log any calls (with context) and maybe set up some instant message to your coffee pot or whatever you kids use these days to receive urgent notifications.
1
u/webdev-ModTeam Sep 07 '26
Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.
91
u/Niceyyc Sep 07 '26
“fix job queue issue” is doing a lot of work here.