With some sprinkle of libraries such as anyhow and thiserror the Rust errors become actually pleasant to use. The vanilla way is indeed painful when you start handling more than one type of error at a time.
Exactly this. Anyhow makes error handling in rust actually a joy. It’s only something you need to consider if you’re writing a library for others to use, and in that case, it’s good that rust forces you to be very very explicit
I actually reasonably like Go. It’s simple and pragmatic but I fucking loathe its error handling. To me it just replicates one of the worst features of C
const ret = trydo_thing();
if( ret ) | result | {
do_something_with_result(result);
}
The try keyword returns any error up; the if-unwrap works with what came out of a successful call. Normally you wouldn’t have both, of course.
do_thing would be defined as a union of an error (a distinct kind of type, so it can be reasoned about with try, catch and unwrapping) and the wrapped return value.
Yeah but Go has the best error handling paradigm of any programming language ever created:
Don’t you just love doing that every 5 lines of code?
It’s not pretty, but it’s uniform, obvious, and easy to understand.
go is good grug friend who chase away complexity demon by limit damage of big brain developer
I don’t like the rust way either. But at least you can unwrap
With some sprinkle of libraries such as
anyhow
andthiserror
the Rust errors become actually pleasant to use. The vanilla way is indeed painful when you start handling more than one type of error at a time.Exactly this. Anyhow makes error handling in rust actually a joy. It’s only something you need to consider if you’re writing a library for others to use, and in that case, it’s good that rust forces you to be very very explicit
Honestly, I do
I actually reasonably like Go. It’s simple and pragmatic but I fucking loathe its error handling. To me it just replicates one of the worst features of C
I do think Zig is better for this kind of thing.
const ret = try do_thing(); if( ret ) | result | { do_something_with_result(result); }
The try keyword returns any error up; the if-unwrap works with what came out of a successful call. Normally you wouldn’t have both, of course.
do_thing would be defined as a union of an error (a distinct kind of type, so it can be reasoned about with try, catch and unwrapping) and the wrapped return value.
That syntax looks atrocious
Well, different floats for different boats I suppose.