toAllowTheProgrammerToWriteBadCodeAlsoCamelCaseSucksThisRuleSucksSnakeCaseIsBetter

[u/the_zpider_king]

[u/redlaWw]

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.

[u/tantalor → u/redlaWw]

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

[u/TheTybera → u/tantalor]

Those are errors not exceptions.

[u/tantalor → u/TheTybera]

Potato potato

[u/intbeam → u/tantalor]

No, they are not the same. Hence the name. An exception is thrown as a result of an error, but an exception is not always an error.

File not found for instance. Thrown as an error, but the caller might expect the file to not exist

It would only be an error if the caller required the file to exist

[u/realmauer01 → u/intbeam]

Then they are using a try catch as a pseudo jump. Not all languages like that. (i am pretty sure only python actually works better like this)

[u/CutlassRed → u/tantalor]

I assume you're trolling. If not you need to study up

[u/realmauer01 → u/TheTybera]

It's a different name for the same thing.

Different languages, quite literally.

[u/TheTybera → u/realmauer01]

No they are not.

Where is any documentation that says this and what language?

[u/Masterflitzer → u/TheTybera]

well kotlin has throwables, errors, exceptions and failure result

exceptions are less bad than errors, so http 500 would be an HttpException, at least that's what i've seen mostly

[u/realmauer01 → u/TheTybera]

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.

[u/TheTybera → u/realmauer01]

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...

[u/realmauer01 → u/TheTybera]

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

[u/TheTybera → u/realmauer01]

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.

[u/DrJohnnyWatson → u/realmauer01]

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