|
|
|
|
|
|
by perarneng
36 days ago
|
|
|
With agentic coding you can just use Rust. AI agents are really good at Rust and the good error message the compiler and or borrow checker gives makes it easy for the AI agent to adjust its code and fix it. For non agentic coding Go has terrible error handling. It does not have exceptions or monadic error handling. Some call that a feature but many avoid Go or that specific reason. This will not change because that debate has been settled so if you can live with if err != nil after each function call (almost) then you are fine. Things that is beautiful with Go are:
* Its simplicity
* Superb cross compilation support and excellent support for many different OS/arch combos. Not sure if anything comes close to this level of easy way of compiling to Many targets and target support. |
|
|
The KEEP for Result<T> goes into details, but basically there are a few ways of handling return values + errors:
1) throw exception if something goes wrong
2) return null if something goes wrong (stdlib XXXorNull)
3) Use Result<T> in some cases, its error type is not paramerized and catches CancellationException
4) Use Arrow if Result<T> doesn't meet your needs
5) Return Sealed Classes / Interfaces with all the possibilities.
Right now, I am going the Sealed Class interface route, but its such a verbose pain in the ass, so I only use it at certain levels of abstraction (like from a Repository, or library API, etc).
The code I needed to write was calling into okio, and it was not straightforward to figure out what kinds of exceptions would be thrown by the JVM layer underneath (docs just say IOException, but sublasses can be thrown).
Its sad to see they still haven't figured this out. Rich Errors was mentioned a year ago but its not even in preview yet. Its also not clear how it will work with Java interop.