this post was submitted on 02 Nov 2025
288 points (96.8% liked)

Programmer Humor

27175 readers
1012 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 23 comments
sorted by: hot top controversial new old
[–] dumples@midwest.social 3 points 1 day ago

I always upvote this. Love this image

[–] arschflugkoerper@feddit.org 21 points 1 day ago* (last edited 1 day ago) (2 children)

.expect("Go fuck yourself.")

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

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

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

Rust programmers writing library code

[–] dejected_warp_core@lemmy.world 4 points 20 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.

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

I do documentation driven developement instead.

[–] flamingo_pinyata@sopuli.xyz 18 points 1 day ago (3 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.

[–] 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.

[–] 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.

[–] lena@gregtech.eu 1 points 1 day ago

I've been learning Elixir and phoenix and love this

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

Elixir and Phoenix make perfect sense for our small team.

[–] 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 1 day ago

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

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

Overrated. ON ERROR RESUME was much more fun.

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

Just a lot of if-elses checking random stuff?

[–] over_clox@lemmy.world 5 points 1 day ago* (last edited 1 day 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...

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

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

[–] henfredemars 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.