You provided an example from Go which is almost like an exception. And I think it is bad. You have a function that returns....something?? Instead, if you have something like Result<T,E>, it tells you exactly what you're getting.
```
value = myFunction();
match value {
Ok(v) => // whatever
Err(MalformedSQL) => // oh something with sql happened?
Err(UserNotFound) => // oh can't find user?
```
Then you get "BZZZZZ, compile error. You forgot to check for another variant of the Error (ThirdPartyLibraryError)" which is a million time better than catch-all exception handling because you are afraid something might get out of this function call. If you do want to have a catch-all exception handling, then that is also possible by using "_ => {}" which is explicit. So just glancing at a piece of code, you know you have handled ALL the possible error cases.
>I have a web application. There is a SQL query that produced no results for an object. I throw an ObjectNotFoundException. It results in an HTTP 404, producing a web page or a JSON response, depending on the request location, and I handle it all once.
Also possible in axum. You have an error enum and then you implement a trait that converts said enum into an HTTP response. So your code looks something like
```
value = myFunction()?;
```
and if there's any error it will automagically turned into the appropriate response. So I get all the ease of exception but the type signature is not lying to me. If I forgot to implement a conversion from some new error to HTTP I get compile time error.
What signature do you get from "if err := myFunction()"?
It's still just a generic error object, possibly a string. You still have to write a handler for it. Why do it every time?
I have a web application. There is a SQL query that produced no results for an object. I throw an ObjectNotFoundException. It results in an HTTP 404, producing a web page or a JSON response, depending on the request location, and I handle it all once.