FAQ
Hi,

   I was wondering why the net.Conn's Read method signature is returning an
'error' and not 'net.Error'? Maybe I just didn't dig around enough, but
don't the implementing structs always return a net.Error?

   E.g. seems a bit awkward to have to cast the error into a net.Error first
to check for a timeout.

   Anyone care to share the reasoning behind it? :)

Thanks,
   Peter

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Mikio Hara at May 17, 2013 at 10:26 am
    because gave its sword to the io.Reader interface.
    On Friday, May 17, 2013 7:07:42 PM UTC+9, Péter Szilágyi wrote:

    Hi,

    I was wondering why the net.Conn's Read method signature is returning an
    'error' and not 'net.Error'? Maybe I just didn't dig around enough, but
    don't the implementing structs always return a net.Error?

    E.g. seems a bit awkward to have to cast the error into a net.Error
    first to check for a timeout.

    Anyone care to share the reasoning behind it? :)

    Thanks,
    Peter
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jesse McNelis at May 17, 2013 at 10:30 am

    On Fri, May 17, 2013 at 8:07 PM, Péter Szilágyi wrote:

    Hi,

    I was wondering why the net.Conn's Read method signature is returning an
    'error' and not 'net.Error'? Maybe I just didn't dig around enough, but
    don't the implementing structs always return a net.Error?

    E.g. seems a bit awkward to have to cast the error into a net.Error
    first to check for a timeout.
    All the APIs do it this way. They return the very general 'error' interface
    that you can type assert to a specific error if you're interested in that.

    Returning a general error makes it easier for people to create interfaces
    that your types can satisfy and allows you to add additional error types
    later without breaking the API.

    --
    =====================
    http://jessta.id.au

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Péter Szilágyi at May 17, 2013 at 12:34 pm
    Makes sense, thanks both :)

    On Fri, May 17, 2013 at 12:28 PM, Jesse McNelis wrote:
    On Fri, May 17, 2013 at 8:07 PM, Péter Szilágyi wrote:

    Hi,

    I was wondering why the net.Conn's Read method signature is returning
    an 'error' and not 'net.Error'? Maybe I just didn't dig around enough, but
    don't the implementing structs always return a net.Error?

    E.g. seems a bit awkward to have to cast the error into a net.Error
    first to check for a timeout.
    All the APIs do it this way. They return the very general 'error'
    interface that you can type assert to a specific error if you're interested
    in that.

    Returning a general error makes it easier for people to create interfaces
    that your types can satisfy and allows you to add additional error types
    later without breaking the API.

    --
    =====================
    http://jessta.id.au
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Bruno Albuquerque at May 17, 2013 at 12:50 pm
    There is still an issue with that. if you want to check for specific error
    codes (for example, let's say you need to know explicitly if the error was
    connection refused), you had to do a string comparison, which seems
    overkill. It would be nice to have the concept of actual error codes.


    On Fri, May 17, 2013 at 9:34 AM, Péter Szilágyi wrote:

    Makes sense, thanks both :)

    On Fri, May 17, 2013 at 12:28 PM, Jesse McNelis wrote:
    On Fri, May 17, 2013 at 8:07 PM, Péter Szilágyi wrote:

    Hi,

    I was wondering why the net.Conn's Read method signature is returning
    an 'error' and not 'net.Error'? Maybe I just didn't dig around enough, but
    don't the implementing structs always return a net.Error?

    E.g. seems a bit awkward to have to cast the error into a net.Error
    first to check for a timeout.
    All the APIs do it this way. They return the very general 'error'
    interface that you can type assert to a specific error if you're interested
    in that.

    Returning a general error makes it easier for people to create interfaces
    that your types can satisfy and allows you to add additional error types
    later without breaking the API.

    --
    =====================
    http://jessta.id.au
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jesse McNelis at May 17, 2013 at 2:19 pm

    On Fri, May 17, 2013 at 10:50 PM, Bruno Albuquerque wrote:

    There is still an issue with that. if you want to check for specific error
    codes (for example, let's say you need to know explicitly if the error was
    connection refused), you had to do a string comparison, which seems
    overkill. It would be nice to have the concept of actual error codes.
    Some packages expose specific error values eg. io.EOF
    Others expose them through specific types eg. net.DNSError

    With net.OpError, if you inspect the net.OpError.Err you eventually get a
    syscall.Errno which gives you the specific error code from the OS. But
    very specific error codes aren't portable which is a good reason to make
    them easy to find.



    --
    =====================
    http://jessta.id.au

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 17, '13 at 10:07a
activeMay 17, '13 at 2:19p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase