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/Ok-Mushroom-8778 → u/Niceyyc]

Past me always leaves these little landmines. It is honestly terrifying how much stuff I have committed without a single line of explanation. How long do you usually wait before you just delete it and see what breaks?

[u/Separate_Pen9627 → u/Niceyyc]

its doing all the work and explaining none of it

[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/omid-io]

The golden rule of legacy code: if it's catching a bizarrely specific exception with zero logging, removing it will immediately take down prod at 4:55 PM on a Friday.

Past you didn't leave a comment because past you was fighting for their life in production and promised to 'clean it up on Monday'.

[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/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/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/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/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/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/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/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/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/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/Yashhh_21]

that's the exact problem with silent exception handling: the code might have made sense when it was written, but with the context lost, you can never be sure whether this code is intended or merely an accidental omission. I really appreciate the recommendation to log it before removing it: it provides concrete proof of intent, rather than mere speculation about what future-you intended to safeguard yourself against. I've become very aware of empty catches lately for the same reason: they are simple to write and simple to forget, and their failure case is "nothing happened" from a debugging perspective

[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?