Go's approach seems pretty sensible... for a dynamically typed language. In a language with static type checking, it seems like you'd want the possible errors to be part of a public function's...
Go's approach seems pretty sensible... for a dynamically typed language.
In a language with static type checking, it seems like you'd want the possible errors to be part of a public function's type, since it's part of the public API? But Java screwed that up and I guess fixing it was deemed too complicated for Go.
Zig has an interesting approach with its inferred error set type, but it's too soon to tell if it will work out at scale.
I don't think that'd really work without modifying the language fairly drastically. In Go's current state, you'd probably have to do something weird like having a package-specific error value with...
I don't think that'd really work without modifying the language fairly drastically. In Go's current state, you'd probably have to do something weird like having a package-specific error value with a error type value and an error message.
Plus when you're making something with a dependency on another thing, you would then have to track down all possible errors your dependencies could return in order to include those in your own API. I don't think I've seen Go documentation ever include what errors are possible, except when that error is particularly notable or common.
I'm definitely no language designer, but I think this is a good compromise.
Yes, I think they made the right decision for Go. Just thinking about other approaches. Zig doesn't ask you to document the set of possible errors. It determines the set of possible errors via...
Yes, I think they made the right decision for Go. Just thinking about other approaches.
Zig doesn't ask you to document the set of possible errors. It determines the set of possible errors via type inference (and automatically puts it in the generated doc), which is neat but probably has its own problems. Consider that upgrading a library that adds a new error to a function could cause code breakage very far away where there's a switch that needs to be adjusted to catch the new error.
But, isn't that sort of what you want? Static checking is for detecting changes like that at compile time, not runtime.
Well, Zig doesn't wrap errors yet so it's not the same, but the basic idea is that in a statically typed language, an error's type should declare what underlying errors are accessible without...
Well, Zig doesn't wrap errors yet so it's not the same, but the basic idea is that in a statically typed language, an error's type should declare what underlying errors are accessible without having to resort to runtime type checks.
I don't think this is practical in Go, though. They get a lot of mileage out of using a single type for all errors and doing everything using dynamic checks. It's a pragmatic solution.
Go's approach seems pretty sensible... for a dynamically typed language.
In a language with static type checking, it seems like you'd want the possible errors to be part of a public function's type, since it's part of the public API? But Java screwed that up and I guess fixing it was deemed too complicated for Go.
Zig has an interesting approach with its inferred error set type, but it's too soon to tell if it will work out at scale.
I don't think that'd really work without modifying the language fairly drastically. In Go's current state, you'd probably have to do something weird like having a package-specific error value with a error type value and an error message.
Plus when you're making something with a dependency on another thing, you would then have to track down all possible errors your dependencies could return in order to include those in your own API. I don't think I've seen Go documentation ever include what errors are possible, except when that error is particularly notable or common.
I'm definitely no language designer, but I think this is a good compromise.
Yes, I think they made the right decision for Go. Just thinking about other approaches.
Zig doesn't ask you to document the set of possible errors. It determines the set of possible errors via type inference (and automatically puts it in the generated doc), which is neat but probably has its own problems. Consider that upgrading a library that adds a new error to a function could cause code breakage very far away where there's a switch that needs to be adjusted to catch the new error.
But, isn't that sort of what you want? Static checking is for detecting changes like that at compile time, not runtime.
What exactly do you mean? Can you provide an example of how it would look like, considering that there are error-values and error-types?
Well, Zig doesn't wrap errors yet so it's not the same, but the basic idea is that in a statically typed language, an error's type should declare what underlying errors are accessible without having to resort to runtime type checks.
I don't think this is practical in Go, though. They get a lot of mileage out of using a single type for all errors and doing everything using dynamic checks. It's a pragmatic solution.