3 ms·

And what if an underlying library returns the exception? All the opposition to exceptions I have encountered are theoretical, and I have never seen it work that

• kajaktum 4y ago
  >What signature do you get from "if err := myFunction()"? 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.