You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any new API addition needs to be supported by requirements which will benefit a wide number of users using the package.
Can you please outline your reasoning behind these new methods? When should the user call Invoke vs Invoke2?
Go usually believes in one way of doing things, so diverging the API at this point does not seem to overshadow the benefit gained by introducing this new API.
I believe the panic was deliberately written for a reason, but I cannot recall it at the moment.
In JS, the constructor (New in syscall/js), and instance methods (Invoke/Call) of JS objects can throw Exceptions. This package converts the thrown Exceptions to panics of type Error. There is usually nothing "exceptional" about these thrown exceptions. They are better suited to be treated as a returned error value, as per @robpike's reasoning for returning error values instead of throwing Exceptions since the early days of Go.
Reasoning:
The syscall/js API was directly based on the gopherjs project, to which I contribute to so I know well.
The New2, Invoke2 and Call2 functions convert the thrown Exceptions to idiomatic Go.
The addition of these new functions will encourage people to use them rather than work with panics (non-idiomatic). This is a benefit!
The naming convention (--2) does not mean "alternative to ...". (Even though they can be thought of as such). It means they return 2 return values, and are 'almost' analogous to the naming convention found in the standard library: eg https://golang.org/pkg/reflect/#Value.Slice3
Sometimes New, Invoke and Call panic for other reasons (these are documented in godoc). They are not effected by this proposal and the behaviour will remain the same.
Activity
agnivade commentedon Feb 22, 2021
Any new API addition needs to be supported by requirements which will benefit a wide number of users using the package.
Can you please outline your reasoning behind these new methods? When should the user call Invoke vs Invoke2?
Go usually believes in one way of doing things, so diverging the API at this point does not seem to overshadow the benefit gained by introducing this new API.
I believe the panic was deliberately written for a reason, but I cannot recall it at the moment.
pjebs commentedon Feb 22, 2021
Let me explain:
A primer for non-JS developers:
In JS, the constructor (
New
insyscall/js
), and instance methods (Invoke/Call
) of JS objects can throw Exceptions. This package converts the thrown Exceptions to panics of typeError
. There is usually nothing "exceptional" about these thrown exceptions. They are better suited to be treated as a returned error value, as per @robpike's reasoning for returning error values instead of throwing Exceptions since the early days of Go.Reasoning:
--2
) does not mean "alternative to ...". (Even though they can be thought of as such). It means they return 2 return values, and are 'almost' analogous to the naming convention found in the standard library: eg https://golang.org/pkg/reflect/#Value.Slice3New
,Invoke
andCall
panic for other reasons (these are documented in godoc). They are not effected by this proposal and the behaviour will remain the same.pjebs commentedon Feb 22, 2021
pjebs commentedon Oct 13, 2021
Any progress on this issue?