undefined | Better HN

0 pointsTheDong3y ago0 comments

> If you need multi-pathed error handling (usually people don't and are just making it out of habit!), worry about what things can do, not what they are.

When I'm looking at an error, it's typically for one of two reasons:

1. To set a correct status code, such as http 5xx (internal server error, our disk flaked) or a 4xx (user error, you gave us invalid input).

2. To provide a better error message, such as to localize it into an error string.

If you're building CLI tools for yourself, sure, every error is fatal and you can read english so you don't need either of those. For most go projects, both of those are relevant concerns for a large number of error paths.

Go's type-system does not help you at all.

Speaking of...

> Well, it's structural, so you don't need other packages to implement an interface rather you need them to accept an interface. That also makes it clear it's a bigger ask - you're not asking a dependency "please also do X" but instead asking "please never need to more than Y".

Yup. That is a big problem. That's the root of the error problem too, where every package returns the stdlib error interface, which is a tiny subset of what you usually want.

0 comments

morelisp3y ago

> To set a correct status code, such as http 5xx (internal server error, our disk flaked) or a 4xx (user error, you gave us invalid input).

For this it's simple to wrap them at return site in something that offers `HTTPStatus() int` and check for implementing that interface, not any concrete types, in your handler.

Also, those error paths should be dangerously hard to mix in the first place, you shouldn't be letting invalid input anywhere near the disk to begin with.

Re. logging interfaces, I think you've missed the point. You want everyone to accept narrow interfaces so you can use the logger you want. You also want everyone to return wide error interfaces so you can categorize the entire universe of possible errors as you want. In the end this isn't a technical problem, it's an "I want everyone to cater for my use case" problem.

TheDongOP3y ago

> For this it's simple to wrap them at return site in something that offers `HTTPStatus() int` and check for implementing that interface, not any concrete types, in your handler.

It's not though, the return site is inside the go stdlib. I cannot annotate it with new methods.

The only way to figure out how to translate all errors (whether to status codes or to other readable messages in localized languages) is to read the code and figure out what errors it might return.

> you want everyone to return wide error interfaces so you can categorize the entire universe of possible errors as you want. In the end this isn't a technical problem, it's an "I want everyone to cater for my use case" problem.

This is a technical problem. In Rust, libraries define error types and return "Result<T, MyErrorType>", which lets a library author decide what errors are interesting or not. If I think they have not classified an error that is useful for a caller, I can file an issue.

In java, exceptions have types, and I can know what types of checked exceptions a function might throw, and can similarly ask for more specific exceptions, or modify the library to provide them.

In go, _every_ library, due to go's error handling idioms and some mis-features of nils/type-inference, returns the most useless error type possible, the 'error' type, and I have to constantly read docs or code to figure out what types it might be.

I don't see how this isn't a technical issue with the language that, at the type-system level, it makes it an anti-pattern to return concretely typed errors in a way the type system can recognize them.

I don't agree with how you're characterizing what I'm saying as being "catering to my use-case".

Do you just never actually need to classify an error? Is it somehow weird to want to be able to provide a localized error to a user? Doesn't everyone have these problems too?

morelisp3y ago

> It's not though, the return site is inside the go stdlib. I cannot annotate it with new methods.

    type httpClientError struct { error }
    func (err httpClientError) HTTPStatus() int { return 400 }
    func (err httpClientError) Unwrap() error { return err.error } // if needed

It's not even anything special around `error`, Go's entire type scaffolding is built around doing stuff like this.

> Do you just never actually need to classify an error?

Infrequently, and virtually never for errors types I didn't write myself (other than a tiny number of sentinels like UnexpectedEOF or DeadlineExceeded).

> Is it somehow weird to want to be able to provide a localized error to a user?

Yes, it's unusual for error details (rather than e.g. outcomes) to be localized for display directly to non-technical end users. This is also true of exception messages in Java. General-propose desktop client software is rarely written in either language.

I think you're too focused on the specific issue to see my general point about interface size.

TheDongOP3y ago

You've constructed 'httpClientError', but how do you end up using it in your program? You have "pkg/httputil" or whatever, and the methods in it return "(Response, error)", not "(Response, httpClientError)".

Even within your own program, you now have to read the code in "httputil" to understand what possible error types can be returned.

It's idiomatic to never return concrete error types, whether from the stdlib, or third party libraries, or even methods within your own program.

Even for types you do write yourself, you still have to either memorize what errors each method may return, or you have to constantly refer to docs or source code reading.

Clearly you think this is fine and go's type system is good enough for your use-cases, but every larger go program I've worked with, error handling has been painful since the errors are effectively untyped.

I assume we must have worked on different types of go projects if you haven't run into pain with this.

> Yes, it's unusual for error details (rather than e.g. outcomes) to be localized

I absolutely agree that it's outcomes which are localized, but to determine _outcomes_, you have to classify errors. If the _outcome_ is "File doesn't exist", that's a different error than "permission denied", so you need to classify. But the type you have is "error", so you have to constantly refer to docs.

1 more reply

j / k navigate · click thread line to collapse

0 comments

morelisp3y ago

> To set a correct status code, such as http 5xx (internal server error, our disk flaked) or a 4xx (user error, you gave us invalid input).

For this it's simple to wrap them at return site in something that offers `HTTPStatus() int` and check for implementing that interface, not any concrete types, in your handler.

Also, those error paths should be dangerously hard to mix in the first place, you shouldn't be letting invalid input anywhere near the disk to begin with.

TheDongOP3y ago

> For this it's simple to wrap them at return site in something that offers `HTTPStatus() int` and check for implementing that interface, not any concrete types, in your handler.

It's not though, the return site is inside the go stdlib. I cannot annotate it with new methods.

The only way to figure out how to translate all errors (whether to status codes or to other readable messages in localized languages) is to read the code and figure out what errors it might return.

In java, exceptions have types, and I can know what types of checked exceptions a function might throw, and can similarly ask for more specific exceptions, or modify the library to provide them.

I don't agree with how you're characterizing what I'm saying as being "catering to my use-case".

Do you just never actually need to classify an error? Is it somehow weird to want to be able to provide a localized error to a user? Doesn't everyone have these problems too?

morelisp3y ago

> It's not though, the return site is inside the go stdlib. I cannot annotate it with new methods.

    type httpClientError struct { error }
    func (err httpClientError) HTTPStatus() int { return 400 }
    func (err httpClientError) Unwrap() error { return err.error } // if needed

It's not even anything special around `error`, Go's entire type scaffolding is built around doing stuff like this.

> Do you just never actually need to classify an error?

Infrequently, and virtually never for errors types I didn't write myself (other than a tiny number of sentinels like UnexpectedEOF or DeadlineExceeded).

> Is it somehow weird to want to be able to provide a localized error to a user?

I think you're too focused on the specific issue to see my general point about interface size.

TheDongOP3y ago

Even within your own program, you now have to read the code in "httputil" to understand what possible error types can be returned.

It's idiomatic to never return concrete error types, whether from the stdlib, or third party libraries, or even methods within your own program.

Even for types you do write yourself, you still have to either memorize what errors each method may return, or you have to constantly refer to docs or source code reading.

I assume we must have worked on different types of go projects if you haven't run into pain with this.

> Yes, it's unusual for error details (rather than e.g. outcomes) to be localized

1 more reply

j / k navigate · click thread line to collapse