This sounds related to #240. Before that PR, there was no clean mapping from js.Undefined to JavaScript's undefined either.

Perhaps this is yet another similar unhanded case. I need to think about it more.

I've honestly almost never dealt with js.Errors, so I can't speak from experience here

js.Error is defined as:

type Error struct {
    *Object
}

I tried your example code and I've noticed if I add these logs:

if result.Object == nil {
    console.Log("result.Object is nil")
}
if result.Object != nil {
    console.Log("result.Object is not nil")
}

Then the output is as expected:

result.Object is nil

Perhaps that's the right way to check if the error was nil? I'm actually not quite sure why a wrapper struct is needed at all. Perhaps it's to enable the Stack method?

Another possibility could've been to expose that via an interface that js errors implement, ala:

var err error
err = foo()
if jserr, ok := err.(js.Error); ok {
    fmt.Println(jserr.Stack())
}

Anyway, I don't think I can comment beyond this, you'll want to wait and see what @neelance says.

Actually, looking at this one piece of code that deals with possible *js.Errors, I'm not sure if that's correct:

https://github.com/gopherjs/websocket/blob/867cdcb6edcfa907c935102a8b91c3d85317747c/wrapper.go#L106-L114

Since it only checks if jsErr is nil and not jsErr.Object.

Edit: Oh, never mind. It doesn't necessarily do something wrong. It'd be the user's responsibility to look at jsErr.Object, presumably.

I don't know about all the internal details. I just know that an object that conforms to the error interface, but can't be checked with != nil like normal errors, is anything but expected :)

If you need my help to dig into the issue a bit, let me know. I'm not afraid of getting my hands dirty, but I really know very little about the internals at play here. But if I need to familiarize myself, I can.

The intention of *js.Error is just to encapsulate a JS error when it is "catched" via Go's recover. It was not meant to be passed to/from JS functions, but it's still possible because of its type signature. However, we may want to reconsider what happens when null gets internalized to such a pointer to a struct. @shurcooL @dominikh Do you think it makes sense to internalize to nil instead of synthesizing a struct and then put nil into the *js.Object field?

Doing if err.Object != nil { is definitely unintuitive, I was trying *js.Error != nil as well. I think part of it is a documentation issue, I didn't even see anything about js.Error or how to handle JS-land callbacks w/ errors etc.

However, we may want to reconsider what happens when null gets internalized to such a pointer to a struct. @shurcooL @dominikh Do you think it makes sense to internalize to nil instead of synthesizing a struct and then put nil into the *js.Object field?

That makes sense to me. Sorry, didn't see this question earlier.

Maybe we try and fix this as part of #617?