this post was submitted on 02 Nov 2025
287 points (96.7% liked)

Programmer Humor

27182 readers
1010 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
top 22 comments
sorted by: hot top controversial new old
[–] arschflugkoerper@feddit.org 21 points 1 day ago* (last edited 1 day ago) (2 children)

.expect("Go fuck yourself.")

[–] Strawberry@lemmy.blahaj.zone 5 points 1 day ago (1 children)

Rust programmers writing library code

[–] dejected_warp_core@lemmy.world 4 points 21 hours ago (1 children)

NGL, writing pure functions in Rust is fantastic. Writing responsible code that handles all the error conditions turns the "happy path" into hamburger. Even with the ergonomics of Result, Option, and even ?, code just sprawls and becomes a readability tradeoff. I'm only a few months into Rust at this point, and I have a lot to learn, but it's tempting to just .unwrap() and .expect() where I think it's unlikely to fail.

[–] Strawberry@lemmy.blahaj.zone 4 points 15 hours ago

That's honestly fine in your application code, but very frustrating to see in library code on crates.io. Nobody wants library code to panic over some nonessential functionality that the calling code could've recovered from.

[–] Qwel@sopuli.xyz 3 points 20 hours ago

"c'mon I just checked that three lines ago"

[–] kubica@fedia.io 20 points 2 days ago (3 children)
[–] Dultas@lemmy.world 7 points 1 day ago

Ah the perl approach. Do x or die("it's fucked")

[–] SpaceNoodle@lemmy.world 5 points 2 days ago

Ah, you must work on our firmware team

[–] affenlehrer@feddit.org 4 points 2 days ago

Yeah, leave some breadcrumbs so the investigators can find out what happened at the crime scene

[–] flamingo_pinyata@sopuli.xyz 17 points 2 days ago (2 children)

Or just code the happy path and let it crash.

(this is actually a real philosophy in the Erlang world and I'm bummed it doesn't receive wider acceptance)

[–] TootSweet@lemmy.world 16 points 1 day ago* (last edited 1 day ago) (2 children)

I can definitely see a lot of good applications for this way of doing things.

It does seem like I often run across "error handling" code that literally just catches a bunch of different exception types and throws a new exception with the same content from the caught error just reworded, adding literally zero helpful information in the process.

It's definitely the case that sometimes the exact sort of crash you'd get if you didn't handle errors is exactly the best sort of exception output the program could do given its particular use case and target audience. Or at least it might be best to let the error be handled much further away in the call stack.

[–] Dultas@lemmy.world 10 points 1 day ago

I've seen a lot worse where they just gobble the original error and throw a new one with 0 of the original context included making it 100x more difficult to debug.

[–] Aceticon@lemmy.dbzer0.com 6 points 1 day ago* (last edited 1 day ago)

At times that shit is pretty much the opposite of what should be done.

Fail Fast is generally a much better way to handle certain risks, especially those around parts of the code which have certain expectations and the code upstream calling it (or even other systems sending it data) gets changed and breaks those expectations: it's much better to just get "BAAM, error + stack trace" the first time you run the code with those upstream changes than have stuff silently fail to work properly and you only find out about it when the database in Production starts getting junk stored in certain fields or some other high impact problem.

You don't want to silently suppress error reporting unless the errors are expected and properly dealt with as part of the process (say, network errors), you want to actually have the code validate early certain things coming in from the outside (be it other code or, even more importantly, other systems) for meeting certain expectations (say, check that a list of things which should never be empty is in fact not empty) and immediatly complain about it.

I've lost count how many times following this strategy has saved me from a small stupid bug (sometimes not even in my system) snowballing into something much worse because of the code silently ignoring that something is not as it's supposed to be.

[–] sirico@feddit.uk 5 points 1 day ago

Elixir and Phoenix make perfect sense for our small team.

[–] irelephant@lemmy.dbzer0.com 7 points 1 day ago

Just a lot of if-elses checking random stuff?

[–] palordrolap@fedia.io 6 points 1 day ago (1 children)

Overrated. ON ERROR RESUME was much more fun.

[–] over_clox@lemmy.world 5 points 2 days ago* (last edited 2 days ago)

Me while doing error handling?

Well shit, all my functions both take and return memory addresses. When one of those blocks of data happen to fail the data sanity check, the function returns either -1, -2, -3, -4.

See, you'll never get such numbers as proper memory addresses, they're assigned as blocks, larger than 4 bytes..

So, if one of my functions returns a -1 through -4, that tells me which argument to the function failed the sanity check...

[–] MonkderVierte@lemmy.zip 3 points 1 day ago

I do documentation driven developement instead.

[–] dumples@midwest.social 3 points 1 day ago

I always upvote this. Love this image

[–] AlecSadler@lemmy.blahaj.zone 2 points 1 day ago (1 children)

I just add a global error catcher and call it good.

[–] henfredemars@infosec.pub 2 points 1 day ago

The best part is there's already a default error handler! If the program dies, you know there was an error.