FAQ
From go1.5, net.OpError would report more consistent error information
across the net package APIs. I propose one more thing; adding
RemoteAddr field to OpError.

The motivation is simply, I don't want to hear, like "urgh, this
application log doesn't show any packet flow. we cannot identify what
happened on which facility." Unfortunately it happens with go1.4 when
we run our applications on top of something complicated computing
virtualization stuff over networking virtulization stuff. Because the
current OpError contains only a single Addr field, and existing APIs
use it to represent either a local endpoint address or a remote
endpoint address. Seems having another field in OpError makes sense.

The change 9231 contains;
- add RemoteAddr field to OpError to represent a remote endpoint address,
- use Addr of OpError to represent only a local endpoint address,
- OpError.Error reports error information including its packet flow
like "read tcp 1.2.3.4:1025->5.6.7.8:1026: something wrong" if
possible.

https://go-review.googlesource.com/#/c/9231/

Does this sound reasonable to you?

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Brad Fitzpatrick at Apr 24, 2015 at 3:51 am
    Does this change the meaning of OpError.Addr then? Did it ever mean remote
    addr, and now it would mean local addr? If so, that seems like we're
    changing semantics on people, which feels like a Go1 API contract violation.

    On Wed, Apr 22, 2015 at 8:39 PM, Mikio Hara wrote:

    From go1.5, net.OpError would report more consistent error information
    across the net package APIs. I propose one more thing; adding
    RemoteAddr field to OpError.

    The motivation is simply, I don't want to hear, like "urgh, this
    application log doesn't show any packet flow. we cannot identify what
    happened on which facility." Unfortunately it happens with go1.4 when
    we run our applications on top of something complicated computing
    virtualization stuff over networking virtulization stuff. Because the
    current OpError contains only a single Addr field, and existing APIs
    use it to represent either a local endpoint address or a remote
    endpoint address. Seems having another field in OpError makes sense.

    The change 9231 contains;
    - add RemoteAddr field to OpError to represent a remote endpoint address,
    - use Addr of OpError to represent only a local endpoint address,
    - OpError.Error reports error information including its packet flow
    like "read tcp 1.2.3.4:1025->5.6.7.8:1026: something wrong" if
    possible.

    https://go-review.googlesource.com/#/c/9231/

    Does this sound reasonable to you?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mikio Hara at Apr 24, 2015 at 4:22 am

    On Fri, Apr 24, 2015 at 12:51 PM, Brad Fitzpatrick wrote:

    Does this change the meaning of OpError.Addr then? Did it ever mean remote
    addr, and now it would mean local addr? If so, that seems like we're
    changing semantics on people, which feels like a Go1 API contract violation.
    Thanks, waiting for such suggestion, though OpError in go1.4 and above
    doesn't set Addr correctly, especially in the case of datagram/raw
    sockets.

    Revised proposal:
    - add LocalAddr and RemoteAddr fields to OpError to represent both
    local and remote endpoint addresses,
    - Addr would be set either a local or remote address, as it was
    before, address on which this error occurred,
    - OpError.Error reports error information including its packet flow
    like "read tcp 1.2.3.4:1025->5.6.7.8:1026: something wrong" if
    possible.

    Does this make sense?

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Apr 24, 2015 at 3:10 pm
    Changing Addr also affects code that uses OpError or creates their own. I
    don't think this is a step to take lightly.

    I disagree that we should deprecate Addr in favor of new fields. The
    implicit claim seems to be that Addr is ambiguous, but it's not: purely
    local operations (like listen) use the local address, and operations
    talking to another system (like dial, read, write) use the remote address.
    Addr is the relevant address for the given operation. Also, see last point:
    Addr is what code expects to be able to use when looking at an OpError, and
    I don't want to invalidate all that existing code.

    I do understand the motivation, that sometimes you need to know what local
    interface you were using in order to understand a failure talking to
    another system. But if we're going to add that we should find a way to
    augment OpError instead of replacing or redefining fields in it. That is,
    Addr should stay, should retain its meaning, should not be deprecated, and
    should not be duplicated by another field.

    Given that the goal is to turn "$Op $Net $Addr: $Err" into "$Op $Net
    XXX->$Addr: $Err", we should be introducing a new field to capture the
    XXX-> but ONLY in the cases where that makes sense. Addr must stay where it
    is, with its current meaning. In particular the OpError returned for Listen
    should be exactly as it is today, with just a zero where the new field is.

    I suggest (modifications in bold):

    type OpError struct {
    // Op is the operation which caused the error, such as
    // "read" or "write".
    Op string
      // Net is the network type on which this error occurred,
    // such as "tcp" or "udp6".
    Net string
      *// For operations involving a remote network connection,*
    * // like Dial, Read, or Write, Source is the corresponding local network
    address.*
    * Source Addr*
    * // Addr is the network address for which this error occurred.*
    * // For local operations, like Listen or SetDeadline, Addr is the*
    * // address of the local endpoint being manipulated.*
    * // For operations involving a remote network connection,*
    * // like Dial, Read, or Write, Addr is the remote address of that
    connection.*
    Addr Addr
      // Err is the error that occurred during the operation.
    Err error
    }

    func (e *OpError) Error() string {
    if e == nil {
    return "<nil>"
    }
    s := e.Op
    if e.Net != "" {
    s += " " + e.Net
    }
    * if e.Source != nil {*
    * s += " " + e.Source.String() + "->"*
    * }*
    if e.Addr != nil {
    * if e.Source == nil {*
    * s += " "*
    * }*
    * s += e.Addr.String()*
    }
    s += ": " + e.Err.Error()
    return s
    }

    Russ

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mikio Hara at Apr 25, 2015 at 1:16 am
    Thanks, a pair of Source and Addr is fine.

    Revised proposal:
    - add Source field to OpError to represent an ancillary local endpoint address,
    - existing Addr field holds either a local or remote endpoint address,
    as an interest, relative address on which an error occurred,
    - OpError.Error reports error information including its packet flow
    like "read tcp 1.2.3.4:1025->5.6.7.8:1026: something wrong" if
    possible.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedApr 23, '15 at 3:39a
activeApr 25, '15 at 1:16a
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase