Please raise an issue https://golang.org/issue/new
On Wednesday, 18 October 2017 16:06:28 UTC+11, bronze man wrote:
>
> 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> 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.
