Also asked this on reddit and the feedback can be found here:
https://www.reddit.com/r/golang/comments/12tsnhf/who_returns_specific_error_interfaces_to_model/
Torben Schinke schrieb am Mittwoch, 19. April 2023 um 12:01:33 UTC+2:
> We are a team of experienced developers and are currently discussing how
> we may improve our modeling of expected domain errors in our layered
> architecture. We are used to work with the idiomatic way of defining and
> matching against our custom error types. We followed and understand the
> design decisions of the error interface and its usage within the standard
> library. However, we are yet dissatisfied with our developer experience due
> to the limited expressiveness. For example, it is quite common to oversee a
> mapping case of an infrastructure error into a domain error. It is clear,
> that we try to document our "error sum type" but without bothering the
> compiler, that is just not helpful enough.
>
> So we are now considering to define custom error interfaces with marker
> methods to represent a sealed set of domain errors. The intention is to
> create the most type safe coupling for error handling, which the Go
> compiler can guarantee - just like we do with regular parameter types. We
> don't need (or want) covariant result types here. And by still using an
> interface, we also avoid the interface-type-not-nil edge case.
>
> *I'm wondering how others deal with this in practice. *
> *Are there any experience reports? *
>
> Example
> // CalculationError defines a sealed set of multiple domain error types
> type CalculationError interface{
> error
> failedCalculation()bool
> }
>
> //...
>
> // ApplyCalculation is more specific about the error and violates
> intentionally idiomatic go but
> // we have a tight coupling anyway.
> func ApplyCalculation(p SomeDomainType)(SomeDomainResult,
> CalculationError){
> //...
> }
>
> related discussions (excerpt)
>
> - https://go.dev/blog/error-handling-and-go
> - https://go.dev/blog/go1.13-errors
> - https://github.com/golang/go/issues/19412#issuecomment-1464178165
> - https://dave.cheney.net/2014/12/24/inspecting-errors
> -
>
> https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
>
> -
> https://blog.merovius.de/posts/2018-01-21-what_even_is_error_handling/
> - ...
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/5a3bb83f-bfe3-43b6-8336-ff0b067dadb2n%40googlegroups.com.
