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