7 ms·
I like Java-style checked exceptions and Rust's Result enums, and my ideal error handling would be more verbose compared to Go's error handling.
by heavyset_go 5y ago
I like Java-style checked exceptions and Rust's Result enums, and my ideal error handling would be more verbose compared to Go's error handling.
- KptMarchewa 5y agoRust's Result type is way less verbose than Go's error handling though. Checked exceptions would have been fine if they composed decently with rest of the language...
- heavyset_go 5y agoWith Rust's result type, you either have to unwrap() them or explicitly handle them with match expressions, whereas if you really wanted to in Go, you could just choose to ignore errors.
- KptMarchewa 5y agoRust has extremely useful "?" operator.
- heavyset_go 5y agoYep, I mentioned that up-thread. It's a very convenient feature.
- deleted 5y ago[deleted]
- foolfoolz 5y agothere’s really no reason this has to be 3 lines if err != nil { return err } i’m hoping they find a way to simplify this
- preseinger 5y agoReturning an unannotated error like this is an antipattern. Every error return should include an annotation via fmt.Errorf.
- nkozyra 5y agoWhy? Errors are annotated by definition. I wouldn't feel better about returning my own string versus the error which already includes a message. How much additional context needs to be there and how often is this convention used by simply duplicating the message with basically repetitive text? panic(err) become "Problem with date formatting: invalid date format" or similar I also think "antipattern" gets thrown around too often. This sounds more like a preference or convention.
- srer 5y agoI presume as a method of manually constructing backtrace, as the same error may occur in multiple places it's helpful to understand the context. I too would label it a preference. To get out of the error handling tedium in our platform I largely opt to panic instead whenever viable, which gives a nice trace for free. (I am but human, and the error handling particularly grates once you have gotten used to just typing `?`.)
- nkozyra 5y agoI also panic whenever possible from the caller, in which case I get a pretty clear stack trace. I understand you don't always want that but imo I don't have a lot of cases where I'm ultimately throwing my hands up on a non-exception error. I think V2 errors are taking more of a lead from the pkg/errors error.Wrap approach anyway.
- preseinger 5y agopkg/errors.Wrap is already accomplished in the stdlib via fmt.Errorf("annotation: %w", err). Programs which use `panic` as ersatz error mechanisms are fundamentally broken. `panic` expresses an invariant violation that's much different than normal errors.