On Mon, Mar 23, 2020 at 10:28 AM Adrian Ratnapala <
adrian.ratnap...@gmail.com> wrote:
> I think this is the classic dynamic vs. static typing trade-off.
I don't fully agree here - I think it's perfectly possible to have all of
the flexibility and all of the static type-checking. I'm having trou
On Mon, 23 Mar 2020 at 11:22, Axel Wagner wrote:
> • A function takes an io.Reader to parse the stream into some data structure
> (think a json-parser). It obviously uses no other input or abstraction or
> state. It makes sense to wrap the error - this allows you to provide
> structured extra
Yes, IMO the decision to expose errors should in general be deliberate.
However, there are cases where it makes sense to wrap from the get-go. Two
examples:
• A function takes an io.Reader to parse the stream into some data
structure (think a json-parser). It obviously uses no other input or
abstr
In my opinion, this is a much nicer errors package than Go's library, and
I've been using it everywhere:
https://github.com/pkg/errors
Instead of fmt.Errorf("%w"), you do errors.Wrap(err, "message"), and
errors.Unwrap(...) where you want to inspect the error. It's much more
explicit and less error
Part of the culture of Go is that we are careful to promise as little
as possible in APIs, as we will be stuck with those promises long into
the future.
Now with Go 1.13 we can do `fmt.Errorf("It broken: %w")` which means
the same thing as `fmt.Errorf("It broken: %v")` except callers get
better w
