On Tue, Feb 5, 2019 at 1:46 PM Robert Engels <reng...@ix.netcom.com> wrote:
>
> If the error doesn’t know what it is wrapping but the caller needs to know
> the wrapped error you have a design problem. It breaks all sorts of ‘isa’
> semantics.
This happens if you're using multiple layers of libraries that don't
know about each other. It is not a design problem.
>
> If you need to know the internal buffer length, you have a design problem.
> What if the wrapped buffer was unlimited or dynamic - there is no length to
> return - you must read until eof.
Sometimes you need to know the internal buffer length if you're
dealing with a service behind a peculiar http front-end, like some
akamai services. You have to send the content length, and if you know
it already, you should be able to get it.
>
> It is not a matter or OO purity, it is a simple matter of encapsulation, and
> not requiring upper layers to know and understand - or even have access to -
> internal details.
Encapsulation is useful if you're hiding internal details. But some
internal details are not so internal under different circumstances,
like the length of a buffer.
>
> > On Feb 5, 2019, at 1:37 PM, Burak Serdar <bser...@ieee.org> wrote:
> >
> >> On Tue, Feb 5, 2019 at 12:22 PM Robert Engels <reng...@ix.netcom.com>
> >> wrote:
> >>
> >> As far as the error handling, this is kind of a limitation of the error
> >> interface in Go and should be solved there. But I would start with asking,
> >> why do you need the causation error? If it is increased logging, then the
> >> higher level error should be able to represent the additional detail when
> >> it is logged. If it is for control flow, then the containing error should
> >> adequately represent the error.
> >
> > That's not always possible if the containing error doesn't really know
> > what it is wrapping. The nested error could be of different types that
> > the wrapper don't know about.
> >
> >>
> >> If you are exposing the length of the underlying buffer higher levels,
> >> that is a design problem. In the Nopcloser you are exposing the reader the
> >> caller already has access to by way of the Reader interface. The Closer is
> >> a decorator. You don’t have access the possibly real Closer in the
> >> original implementation. There is no GetWrappedCloser.
> >
> > Note that the inability to expose the underlying buffer length is the
> > problem here. The only safe way to get the length of the buffer, in
> > this case, is to copy it.
> >
> >>
> >> I would also argue that Nopcloser is a poor design. You are passing a
> >> object around where the Close that the object is exposing is no longer
> >> called. This can lead to very brittle code and obscure bugs - the object
> >> is no longer behaving the way the designer expected. The Closer interface
> >> expects that the resource will be closed, this is now broken.
> >
> > You are approaching this as an OO-purist. In my opinion, NopCloser is
> > a simple adapter that wraps readers without a close(). If it wasn't in
> > the library, it would've been rewritten in many projects.
> >
> >>
> >> Much of a Gos dynamic interfaces though work poorly this way... but that
> >> is another discussion.
> >>
> >>>> On Feb 5, 2019, at 12:33 PM, Burak Serdar <bser...@ieee.org> wrote:
> >>>>
> >>>> On Tue, Feb 5, 2019 at 11:27 AM Robert Engels <reng...@ix.netcom.com>
> >>>> wrote:
> >>>>
> >>>> But even then, exposing internal details outward leads to lots of
> >>>> problems, testability for certain. There’s almost always a better way
> >>>> then GetNested, GetWrapped, or any of its derivatives.
> >>>
> >>> How so? How would you deal with something like error wrapping, for
> >>> instance? Or in this specific case, how would you get the length of
> >>> the underlying buffer if you wrap the reader with a NopCloser?
> >>>
> >>>>
> >>>>> On Feb 5, 2019, at 12:20 PM, Robert Engels <reng...@ix.netcom.com>
> >>>>> wrote:
> >>>>>
> >>>>> Then you want inheritance not encapsulation.
> >>>>>
> >>>>>>> On Feb 5, 2019, at 10:46 AM, Burak Serdar <bser...@ieee.org> wrote:
> >>>>>>>
> >>>>>>> On Tue, Feb 5, 2019 at 9:41 AM Robert Engels <reng...@ix.netcom.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> GetNested anything is a sign something is broken in the API. The
> >>>>>>> whole point of being nested is almost always encapsulation and then
> >>>>>>> you are breaking it.
> >>>>>>
> >>>>>> That's too much of a generalization in my opinion. This is more like
> >>>>>> decoration, adding new functionality at every layer, but there is no
> >>>>>> way to expose all the functionality of the nested thing, so you need
> >>>>>> to expose the thing itself.
> >>>>>>
> >>>>>>>
> >>>>>>>>> On Feb 5, 2019, at 10:30 AM, Burak Serdar <bser...@ieee.org> wrote:
> >>>>>>>>>
> >>>>>>>>> On Tue, Feb 5, 2019 at 9:12 AM <matteo.biage...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> I've the following situation:
> >>>>>>>>> I proxy a request to another server and when I made a POST and
> >>>>>>>>> create a new request, the contentLength is zero:
> >>>>>>>>>
> >>>>>>>>> req2, _ := http.NewRequest(req.Method, newApiUrl , req.Body)
> >>>>>>>>> fmt.Println("New request from body:", req2.ContentLength) //
> >>>>>>>>> print 0
> >>>>>>>>>
> >>>>>>>>> Checking in the source code of the NewRequest func Body don't
> >>>>>>>>> respect some interface and populate the ContentLength field.
> >>>>>>>>
> >>>>>>>> When the first request is created, req.Body is set to a NopCloser,
> >>>>>>>> and
> >>>>>>>> that doesn't match any of the cases in the second NewRequest. For
> >>>>>>>> this
> >>>>>>>> to work, I guess the best way is to get the body length and set it
> >>>>>>>> explicitly after constructing the second request.
> >>>>>>>>
> >>>>>>>> I don't know if this is intentional or not, but in general, it might
> >>>>>>>> be a good idea to add a ReaderWrapper interface to the standard
> >>>>>>>> library that defines a GetNestedReader() io.Reader function to access
> >>>>>>>> the real reader from these utility classes.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Could be a bug? Which could be a valid approach in order to create
> >>>>>>>>> a new request from an existing one and correct set the Body length?
> >>>>>>>>>
> >>>>>>>>> A working example here:
> >>>>>>>>>
> >>>>>>>>> https://play.golang.org/p/SvCDLj0NrXb
> >>>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> 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.
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> 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.
> >>>>
> >>>> --
> >>>> 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.
> >>
> >> --
> >> 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.
>
> --
> 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.
--
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.
