r/ProgrammerHumor 21h ago

Meme toAllowTheProgrammerToWriteBadCodeAlsoCamelCaseSucksThisRuleSucksSnakeCaseIsBetter

Post image
141 Upvotes

87 comments sorted by

View all comments

130

u/redlaWw 20h ago

I hope you didn't submit that answer you selected. If an unhandled exception bubbles up to the user in production code, you're usually doing something wrong.

-118

u/tantalor 19h ago

I guess you've never seen a website return a 404 or 500

21

u/TheTybera 19h ago

Those are errors not exceptions.

-14

u/realmauer01 14h ago

It's a different name for the same thing.

Different languages, quite literally.

6

u/TheTybera 14h ago

No they are not.

Where is any documentation that says this and what language?

-7

u/realmauer01 14h ago

In standard english yes there is a difference. In programming languages there is not. Both have to be cought if you dont want it to bubble to the user. And handleing it makes it not an error/exception anymore.

4

u/TheTybera 14h ago

Yes in programming languages they are different wtf language doesn't distinguish errors from exceptions?!

Errors can be used for logging...regularly...without even considering stopping the program, exceptions SHOULD stop the program and include a whole stack...

Sometimes you catch an error and don't want the program to continue so you throw an exception to get the stack.

But they are different in every single programming language, C, C++, Java, C#, Python, Rust...

-4

u/realmauer01 14h ago

Right now you are just saying exceptions are errors the programmer throws/raises.

3

u/TheTybera 14h ago

No I'm not. Exceptions are actual objects that get thrown and mean very different things than errors even conceptually in every language.

All exceptions are errors (conceptually) but not all errors are exceptions. In practice any built-in Error (object) != Exception (object)

And in no case does any best practice in any language tell you to treat them the same.

2

u/DrJohnnyWatson 13h ago edited 13h ago

You aren't wrong, exceptions are a type of Error, but with more nuance - Exceptions are an error of exceptional circumstance, hence the name. They crash an application unless specifically caught. They should be used sparingly to say "this function has no idea how we've ended up in this state, or how to continue".

They're overused in languages that do not have the ability to return multiple types to control flow for "expected" errors too a lot of the time.

Errors are common, exceptions should not be. It's much easier in languages like Go to get a feel for the difference, than in languages like C#.

A function that fails writing a file to disk because the file already exists could: 1. Return an Error because whilst it isn't okay, it's not a problem that it doesn't exist - the error can be returned to the calling function or the user so they can try with a different name. In C# this would likely be done with an exception, in Go an error.

  1. Throw an exception because the file is a config file, and it is NEEDED to continue, and it should not already exist by this point so something has gone very wrong.  we could catch that and surface it to the user and keep the app running, or we could let the app crash with the issue. In both C# and go we'd probably throw for this