Remix clone Hacker News

When I started trying to teach myself Rust, the error handling story fell apart on me very quick.

Like as soon as I wanted to try and get sensible reporting in their, suddenly we were relieving libraries, adding shims and fighting mismatched types and every article was saying the same thing: haha yeah it's kind of a problem.

I'm very, very unsold on explicit error handling compared to exceptions for practical programming. The number of things which can error in a program is far larger then those that can't.

▲

lkirkwood a day ago | parent | next [-]

I felt the same but after switching to anyhow and thiserror in pretty much every Rust project I work on I find it quite painless. It's not ideal to rely on crates for a core language feature but I never find myself fighting error types anymore. Have you tried those crates? Do you still hold that opinion?

	▲	masklinn a day ago \| parent [-]
		You don’t need crates for it, anyhow is basically a better Box<dyn Error>, if you just want the error signal you can use that. The main thing missing from the stdlib fur this use case is I don’t think there’s anything to easily wrap / contextualise errors built in.

▲

usrnm a day ago | parent | prev [-]

The problems you're describing don't exist in go. There is exactly one standard type that is used by everyone, at least in public API's, you can always just return the error to the caller, if you don't want to handle it in place. The main difference with exceptions in my practice is the fact that it's a lot easier to mess up, since it requires manual typing. This is probably my main problem with everything being as explicit as possible: it requires people to not make mistakes while performing boring manual tasks. What could possibly go wrong?

	▲	Yoric a day ago \| parent \| next [-]
		The drawback, on the other hand, is that all the Go code I've read (including the stdlib and all the dependencies of my current project) is using `fmt.Errorf` or `errors.New`, which means that you can't use `errors.As`, which means that you generally cannot handle errors at all.
	▲	XorNot a day ago \| parent \| prev [-]
		I think that sort of nails it: the problem with errors as values is errors become part of the type signature and put under user control, and the user can't really be trusted with that power. Even the simplest functions tend to have error states - i.e. floating point math can always wind up handing back NaN. So where I end up is, the default assumption is every function is effectively of a type MightError(T)...so why even make us type this? Why not just assume it, assume the unwrap handling code, and so you basically wind up back at try-catch exception handling as a syntactic sugar for that whole system.