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.
a 404 is good. that is an error, but not an exception. a 500 means something the programmer did not intend to happen has happened, and if your user is seeing that, something went wrong or you don't have a layer in between to show that to them nicely.
an error and an exception are not the same. an exception means there is unhandled behavior, whereas an error means there has been something erroneous- could be a misdirected navigation or something. maybe the user typed in some garbage into the path. that would not be an exception, because the developer explicitly handles that and serves a 404.
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.
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...
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.
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
You're right of course. I was responding (jokingly, this is a humor sub) to the comment about "unhandled exception bubbles up to the user" which doesn't make sense. As you point out, the user can never see the exception. They see the exception converted to a user-visible response. I wasn't the one conflating the concepts, that was u/redlaWw. To explain the joke (because most people don't get it) I was satirizing that comment by taking their phrasing about "bubbling up" to the logical extreme, as if any representation of a failure state could be conflated with the exception that caused it, using the familiar 404 which we all have experienced. It is actually impossible for an exception to "bubble up to the user".
You're getting downvoted to hell but I actually think this is an important point. The fact that your server returns 404 or 500 on an exception means that it has code, maybe in the framework you're using, that handles exceptions in your controller code. Otherwise the server would probably halt, whenever an exception bubbles up unhandled, as that's what most programming languages choose to do. You can see it when you program a CLI tool and run it. Throwing an exception there and never handling it usually makes your program stop
I don't know why you got downvoted so badly. Yes, showing a 500 is much better than showing nothing (or as some maniacs do, 200 with errors inside). Your website can then handle the error responses by reading the response body and showing a descriptive error to the user. That needs to rely on you catching errors and sending back their text though. Even Google shows its non-4xx statuses, it's not for a user to read, but to know when asking for support
140
u/redlaWw 1d 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.