1个月前

Slapping on a `.expect` is also error handling!

Don't say anyway, say anyhow

29 留言

- Sad to be the one that does not get it.
  
  Unwrap means it forces to evaluate the result as an ”ok value”. If it’s an ”error value”, it will crash. It’s a bad practice to rely on it, as it’s one of the most common ways a Rust programs can crash.
  Rust offers many options to handle errors that don’t risk crashing. For example, unwrap_or_default, which means ”if it’s an error value, use the default value for this type, such as 0 for integers”
  
  Languages like Java or C++ have Exceptions, which are errors, that are not explicitly mentioned in the function signature. Meaning, you might need to handle an exception you didn't even know existed. And if you don't, your program will just crash when these exceptions occur.
  In Rust all errors are explicitly mentioned and part of the return type. Because of this Rust has a lot of ways to quickly handle an error. One of those ways is "Trust me, bro" (or .unwrap()), which converts the combined error/success return type into just a success type, causing the program to crash if it actually was an error, restoring the more unsafe behavior of other languages.
- every 20 lines.. haha that's so much.. visibly sweating

I prefer it over alternatives:
Exceptions: ”Oh no! Guess I’ll just die”
Error codes: ”If a non-zero error code is returned but no one notices, is it really an error?”
- The crash early, crash often approach of Erlang has made for some amazingly resilient systems.
  One time on a project I was working on, some horribly broken code was merged (nobody in the team had even heard of reviewing code). As soon as a specific call was made, it was executed once and then the thread crashed. The only way we noticed was that response times increased with load. All data and behavior was still correct. Whole nodes could go down and all you notice is a dip in performance until it comes back online.
  Of course it requires special care in designing. Everything runs in stateless server threads with supervisors restarting them as needed. This in turn requires some language support, like lightweight threads. Our application would happily run tens of thousands of threads on an ancient sparkstation.
- It is a nicer way I think. But other languages do allow for good exception handling. It's just there's not a clear cut sign that no-one has handled the exception yet. So often it doesn't get handled.
  What I mean by that is. If I have a function that returns say a string. As a caller, you don't know whether that function is always going to return a string (it handled exceptions internally), or if it returns a string but might return an exception. So you need to try/catch (or whatever is the equivalent in that language). It's not clear to the caller.
  Whereas with rust, if you're holding a value wrapped in a result, it means that any exception hasn't been handled yet. If you're not passing the value (still inside the result) back to a caller, tag you're it! :P
  
  I like the flexibility Rust offers with the result type. It makes the error handling part of the control flow rather than an afterthought.

undefined

try { execute.SomeMethod(); } catch(Exception ex) {}
- goto fail;
- I've seen this in production code before. I might argue if you caught a very specific exception type that didn't matter it might be acceptable. Maybe. But just the overall Exception type... Recipe for disaster.
  
  What really sucks, imho, is that lazy programmers won in java's checked exception wars.
  With checked exceptions you have to type a little more, but it means that you can be sure you caught every exception type.
  By making everything into a runtime exception you never know if you caught all relevant types of exceptions.
  Which then again leads to people blanket-catching Exception because that way the app will at least not randomly crash due to a forgotten catch for some obscure exception type.
  It's a trash solution for a trash problem caused by lazyness even though there was a real solution available all along.

Elixir {:error, IDK lol}

29 留言