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.
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.
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.
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.
