4 ms·
I mean...I'll say this, for all the great things spoken about it I also found myself wildly disappointed with Rust's error handling when I tried to use it (and
by XorNot 2y ago
I mean...I'll say this, for all the great things spoken about it I also found myself wildly disappointed with Rust's error handling when I tried to use it (and then a pile of blog posts going "oh yeah, it does kind of suck...").
What I am yet to find in any programming language is a reliable way to put my cursor somewhere in the code base, and know exactly all the possible errors which can happen, where they could come from, and whether I've handled them (or might be interested in handling them).
Fault-injection is also consistently a sore point - i.e. in Go if you're doing an os.Open(somefile) call - it'd be really nice if writing code which tests the failure path was just easier - i.e. most of the time I'm saying "this Open on this line, just return an error for this test case so I can make sure it does what I want" - without bogging myself down in dependency injection or call monitoring (i.e. realistically I just want to say "os.Open in file somefile.go, line 143 - for this test please just return err"). Yes something like this can be done, but can we really not make this easier? Write tools which make this easier?
- rto_victim 2y agoAgreed. Sum types require too much boilerplate for error handling as they require wrapping and unwrapping which leads to people creating crate-level error enums that have every possible injection. Ideally we'd have unions which gets rid of the bike shedding that comes with sums [1]. [1]: https://gvolpe.com/blog/error-handling-scala3/ https://gvolpe.com/blog/error-handling-scala3/
- andyferris 2y agoRoc's polymorphic tagged unions seem to be the sweet spot of not requiring specially-crafted enums or multiple levels of unwrapping, yet having lots of statically-checked guarantees. (Zig is similar but doesn't support different types of payloads on the different error values).
- tubthumper8 2y agoUntagged unions lack the ability to model "the success value is a string and the error is a string", right?
- rto_victim 2y agoThat's correct. In your case you can either model it with a sum type or wrap each variant in its own type and take the union of them. Example: enum Result { Success(String), Error(String), } struct Success(String); struct Error(String); type Result = Success | Error;
- fao_ 2y ago> What I am yet to find in any programming language is a reliable way to put my cursor somewhere in the code base, and know exactly all the possible errors which can happen, where they could come from, and whether I've handled them (or might be interested in handling them). Zig's error types and error unions seem like a decent approach to achieve this.
- metaltyphoon 2y agoExcept they can’t carry extra information with it
- threeseed 2y ago> What I am yet to find in any programming language is a reliable way to put my cursor somewhere in the code base, and know exactly all the possible errors which can happen, where they could come from, and whether I've handled them You can do this in Scala with an IO type e.g ZIO. All functions have a return type of IO[Success, Error] and it will always return one or the other.
- dingnuts 2y agoyeah but then you have to put up with the rest of Scala, and worse, the ecosystem
- tadfisher 2y agoThis is not a helpful comment.
- fire_lake 2y agoScala has exceptions so this is untrue no?
- hocuspocus 2y agoCats Effect and ZIO eventually catch unhandled exceptions but you are right, there's no way to know for sure, we're merely assuming that 1) Scala libraries have a sane behavior (i.e. no exceptions at all) 2) the developer is familiar with the Java libraries they're wrapping and will use IO.attempt pervasively. However, in the near future, the compiler itself should be able to handle all exceptions statically: - https://docs.scala-lang.org/scala3/reference/experimental/canthrow.html https://docs.scala-lang.org/scala3/reference/experimental/ca... - https://docs.scala-lang.org/scala3/reference/experimental/cc.html https://docs.scala-lang.org/scala3/reference/experimental/cc...
- elcritch 2y agoI've been enjoying the improvements in Nim's effect system lately. The Nim LSP recently added the ability to see the exceptions any function can result in. It's been pretty handy. Well when the LSP isn't crashing like a seive at least (it's getting better slowly). The LSP doesn't show where the exceptions are raised from, but that'd be cool. Even just having a link to pull up a search for a given exception would be handy.