I already found this bug yesterday.
I am thinking why not golang team just fix this bug by change code?
It looks easier to fix this bug then to document this bug.
On Tuesday, October 17, 2017 at 11:59:42 AM UTC+8, Ian Lance Taylor wrote:
>
> On Mon, Oct 16, 2017 at 8:17 PM, bronze man <bronz...@gmail.com
> <javascript:>> wrote:
> >
> > In the file /usr/local/go/src/syscall/dll_windows.go:300
> >
> > Is there any use case to use the always non-nil error obj?
> >
> > That is a strange design.I think I need to write my version of LazyProc.
> >
> > I can write something like following to work around this:
> >
> > func IsSyscallErrorHappen(err error) bool{
> > if err==nil{
> > return false
> > }
> > errNo,ok:=err.(syscall.Errno)
> > if ok && errNo==0{
> > return false
> > }
> > return true
> > }
>
> I think this is probably a bug in syscall.(*Proc).Call. It returns
> the type error, and is mostly implement by calling syscall.Syscall
> which returns the type Errno. Assigning an Errno to an error will
> never give you a nil error. It should change to something like
> r1, r2, errno = syscall.Syscall(...)
> if errno != 0 {
> err = errno
> }
> return
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
