On Fri, Sep 23, 2016, at 08:03 AM, Ahmy Yulrizka wrote:
> I understand that, I dont either. But what's the idea behind not
> having it at the first place? Is there more to it other than make it
> more simple?
One possibility is that it reduces the number of allocations (for
storing frame pointers)
On Fri, Sep 23, 2016 at 9:03 AM Ahmy Yulrizka wrote:
> I understand that, I dont either. But what's the idea behind not having
it at the first place? Is there more to it other than make it more simple?
Being it an interface, it's universal. One can choose a simple number,
string, etc. to be an e
I understand that, I dont either. But what's the idea behind not having it
at the first place? Is there more to it other than make it more simple?
On Fri, Sep 23, 2016, 8:29 AM Jan Mercl <0xj...@gmail.com> wrote:
> Nothing prevents you from including the call stack in the error message.
> Especia
A minor clarification. An error is any value that implements this interface
type error interface {
Error() string
}
Functions like errors.New and fmt.Errorf return an error implementation who's
base type (kind) is a string, but this is an implementation detail, there are
plenty of othe
Nothing prevents you from including the call stack in the error message.
Especially if you prefer the way how Java error messages look.
I don't.
On Fri, Sep 23, 2016, 08:24 Yulrizka wrote:
> Hello
>
> I was watching Dave Cheney's presentation in gopher conf and was
> fascinated.
>
> (btw he als
Hello
I was watching Dave Cheney's presentation in gopher conf and was fascinated.
(btw he also wrote a blog post here
http://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully)
In some case, I can relate. For example when I'm working on quite large
codebase, Sometimes I
