On Mon, Sep 20, 2021 at 10:52 PM Andrey T.
wrote:
>
> ... or, to put a crazy idea out there, we need to ask for extension of
> switch statement to support (v, err) tuples for a case argument...
That's not a particularly crazy idea. It's just one that's unlikely to make
it through with one
... or, to put a crazy idea out there, we need to ask for extension of
switch statement to support (v, err) tuples for a case argument...
On Sunday, September 19, 2021 at 3:43:36 PM UTC-6 david@gmail.com wrote:
> On Sun, Sep 19, 2021 at 5:19 PM roger peppe wrote:
>
>> In some ways, the
On Sun, Sep 19, 2021 at 5:19 PM roger peppe wrote:
> In some ways, the existing API is arguably more ergonomic than the
> originally proposed generic version, as it's possible to use `errors.As` in
> a switch statement (eg to test several possible types of error) which isn't
> possible with the
In some ways, the existing API is arguably more ergonomic than the
originally proposed generic version, as it's possible to use `errors.As` in
a switch statement (eg to test several possible types of error) which isn't
possible with the multi-return `As` variant.
A minor variant of the existing
On Sun, Sep 19, 2021 at 4:02 PM David Finkel wrote:
> You might be interested in the original draft proposal for errors.As:
>
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
>
> In particular, it originally specified that errors.As
You might be interested in the original draft proposal for errors.As:
https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
In particular, it originally specified that errors.As would take a
type-parameter. (the version of generics that was
I like the way error handling is done in the xerror package. Things become
more concise, but remain very easy to read and understand as in plain Go
errorhandling.
Here is the example of how to use xerror.As:
_, err := os.Open("non-existing")
if err != nil {
var pathError
