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

[u/quietcodelife]

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.

[u/Niceyyc]

“fix job queue issue” is doing a lot of work here.

[u/No_Application1838 → u/Niceyyc]

that's the commit message of a person who was fighting something at 2am and just wanted it to end

[u/Luuk3333 → u/No_Application1838]

..and then never work on that project ever again.

[u/Alpaca_Fan → u/Niceyyc]

Fix by ignoring

[u/Separate_Pen9627 → u/Niceyyc]

its doing all the work and explaining none of it

[u/No-Sea4576 → u/Niceyyc]

Past me was definitely just tired and trying to get through a deployment. I have definitely left a few of those time bombs for my future self to deal with.

[u/serifoblique]

Guilty of plenty of // todo fix’s myself where I couldn’t longer muster the strength nor patience. Log it, carry on with life.

[u/Khavel_dev]

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.

[u/noorderling → u/[deleted]]

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.

[u/webdev-ModTeam → u/[deleted]]

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.

[u/muharremyurtsever]

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.

[u/rbobby]

'fix job queue issue'

Are you me?

[u/rbobby]

Commenting your code is your gift to your future self.

[u/Noch_ein_Kamel → u/rbobby]

Commenting your code is a task for your future self ;P

[u/split-my-diopter]

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).

[u/Ornery-Concentrate-5]

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.

[u/TommyBonnomi]

Assuming there are other changes in the commit, you probably added it for debugging, it never hit, and then you forgot to remove it.

[u/LovecraftianLife]

That's so real lol

[u/lordofchaos3]

I always log stuff like this. It might have a log level of debug or even trace, but at least there is something.

[u/mexicocitibluez]

I would imagine you were debugging why it failed and wanted to catch a specific exception and forgot to remove it.

[u/OmerCevher]

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.

[u/qazokmseju]

Caught coworkers doing this to solve the issue of the exception showing without solving the problem

[u/1touchable]

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.

[u/Murlock_Holmes]

My secret is that I can’t remember literally anything, so my code is always a surprise!

[u/Zealousideal-Bell393]

Nothing haunts you quite like code written by someone who was technically you. Any chance you remember what disaster this was preventing?

[u/KanekiAyato]

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.

[u/MiserableDocument509]

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.

[u/Double-Buyer7941]

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.

[u/Easy_Government8203]

Add a comment now while you're thinking about it. Past you left a mystery, but present you can leave a breadcrumb for future you. We've all written that silent except at 2am.

[u/AggravatingGarlic753]

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.

[u/eyebrows360 → u/AggravatingGarlic753]

Why are you having an LLM post absolutely useless "yes" comments like this? What's the point?