this post was submitted on 02 Nov 2025
181 points (98.9% liked)

Programmer Humor

38960 readers
998 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 6 years ago
MODERATORS
 

Increasingly so, the more experienced I get...

top 15 comments
sorted by: hot top controversial new old
[–] HiddenLayer555@lemmy.ml 17 points 18 hours ago* (last edited 17 hours ago)

Proprietary software be like:

try:
    whatever()
except Exception:
    print("oops something went wrong uwu")
    print("also this is purely to get rid of the stack trace because apparently the only thing worse than not handling an exception is scaring the user with anything technical and/or exposing our trade secret architecture")
[–] limer@lemmy.ml 6 points 18 hours ago (2 children)

I use the catastrophe theory of error handling: if something fails sanity checks or throws an exception, then kill it with fire: crash the whole program and make the users cry.

True, it’s a pain but.. no more hidden errors that get reported two years later

[–] Vinapocalypse@lemmy.ml 2 points 6 hours ago (1 children)

actually a really bad idea if you're doing anything with critical data between your systems and other systems, like a credit card getting charged on a remote server but then your code crashes

[–] limer@lemmy.ml 4 points 6 hours ago* (last edited 6 hours ago)

Dev mode is when developing by the programmers. Production means used by others.

When I am working with a service, I want to know immediately when there is a problem.

When I push my code to be used, the dev flag is off and the code does stuff as normal.

For example: if I am making a payment service using a third party, I use sandbox and fake cc numbers. I want things to fail loudly on my computer so I can make things fail silently. And safely, when it’s used with real money. But I can only do that if I know there are issues. And only logging lets some bugs be unnoticed , particularly if a cluttered log. So being loud in development saves tears in production

[–] Ephera@lemmy.ml 2 points 16 hours ago (1 children)

I agree in general, that a crash is much better than silently failing, but well, to give you some of the nuance I've already mostly figured out:

  • In a script or CLI, you may never need to move beyond just crashing.
  • In a GUI application or app, a crash may be good (so long as unsaved data can be recovered), but you likely need to collect additional information for what the program was doing when the crash happened.
  • In a backend service, a crash can be problematic when it isn't actually necessary, since it can be abused for Denial-of-Service attacks. Still infinitely better than failing silently, but yeah, you gotta invest into logging, monitoring and alerting, so you don't need to crash to make it visible.
  • In a library, you generally don't want to trigger a crash, unless an irrecoverable error happens, because you don't know where it'll be used.
[–] limer@lemmy.ml 2 points 9 hours ago* (last edited 6 hours ago)

All good points!

Also, I’ve learned from others that how you crash depends on the environment, if running in dev, be different than if the thing is used by the public or in production.

  • In a script, dump too much data if dev, in production keep it terse but have relevant info and a link to the docs.
  • In a gui, webpage or app make the crash screen in dev be a thing of beauty that has the full stack trace, database info , and more. But in production only generate a polite message that is vague, with an error code. Push that error to a logging service with the code. And if this is not used by the public but by a company that paid for it, have a feedback button or live chat button, in the error message, to talk with tech support.
  • Backend services and libraries: if in dev mode crashes should be loud and definitely break things, while in production log silently and keep working.
  • And for any type of program: always back up data, and always use transactions to not have the database or files be in an incomplete state if an exception happens.

formatting edit

[–] einkorn@feddit.org 12 points 1 day ago (1 children)

Increasingly so, the more experienced I get...

Knowledge is a curse!

[–] Lemmyoutofhere@lemmy.ca 4 points 1 day ago (1 children)

The more you know, the more you realise you don’t know.

[–] limer@lemmy.ml 2 points 4 hours ago

When I graduated with my bs in programming I thought I had at least a little knowledge of most programming

Years later, I can safely say I know very little, maybe aware of 1% or 2% of just the names of the major parts of tech in programming . Details even less.

And I read a lot

[–] AnUnusualRelic@lemmy.world 4 points 1 day ago

print "error \n"

There, handled.

[–] Ephera@lemmy.ml 8 points 1 day ago (2 children)

Currently implementing error handling for a library I'm building and the process is basically to just throw all of the information I can find into there. It makes the error handling code quite verbose, but there's no easy way for me to know whether the underlying errors expose that information already, so this is actually easier to deal with. 🫠

[–] Ithral@lemmy.blahaj.zone 3 points 10 hours ago

Thank you, I hate it when libraries fail and don't give me good info, like failed to load doesn't help, failed to load because of syntax error on line 45 of input is soooo nice when that happens.

[–] Dojan@pawb.social 6 points 1 day ago

I appreciate verbosity. It’s much nicer than the opposite.

[–] GhostlyPixel@lemmy.world 5 points 1 day ago

Maybe one more log output would fix it…

[–] rizzothesmall@sh.itjust.works 2 points 1 day ago* (last edited 1 day ago)

Welcome to the second part of the Dunning Kruger wild ride of software.