Programmer Humor

38960 readers

307 users here now

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

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 6 years ago

MODERATORS

AgreeableLandscape@lemmy.ml

cat_programmer@lemmy.ml

182

Me, when doing error handling (lemmy.ml)

submitted 1 day ago* (last edited 1 day ago) by Ephera@lemmy.ml to c/programmerhumor@lemmy.ml

15 comments fedilink hide all child comments

Increasingly so, the more experienced I get...

you are viewing a single comment's thread
view the rest of the comments

[–] Ephera@lemmy.ml 2 points 22 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 15 hours ago* (last edited 13 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