Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tour:rot13Reader hint #12880

Open
jonburgin opened this issue Oct 8, 2015 · 5 comments

Comments

@jonburgin
Copy link

commented Oct 8, 2015

Context: http://tour.golang.org/methods/12

Great tutorial!
If I may humbly suggest, it would have helped me to be told that all characters in a reader should be processed even if there is an error. I put a guard statement to not bother to do the rot13 if the enclosed reader returned an error, for efficiency reasons. Although obvious after the fact, I didn't discover the source of my problem until I read the docs on Reader.

@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Oct 8, 2015

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2015

@rakyll

This comment has been minimized.

Copy link
Member

commented Oct 13, 2015

it would have helped me to be told that all characters in a reader should be processed even if there is an error.

Is it? func (r rot13Reader) Read can return an error anytime and you can don't have to consume all the characters from s if an error happens -- even though I don't see where an error can happen in this particular exercise during Read. Could you provide a snippet from your solution to make it a bit clear?

@jonburgin

This comment has been minimized.

Copy link
Author

commented Oct 13, 2015

There isn't a problem with the exercise, just my ignorance, but basically
I did a guard pattern, to prevent doing extra work.
Sorry about the syntax, I'm doing this off the top of my head and I'm still
a 'go' novice
I did something like:

if count, err := otherReader.read(myByteBuffer); err{ return 0, err

}
//do rot13 code here

But when I did that, none of the data was returned. I should have processed
the data as well, since the original reader returned both all the data AND
an EOF

The reference docs, that clued me in can be found at:

https://golang.org/pkg/io/#Reader

Specifically: "Callers should always process the n > 0 bytes returned
before considering the error err.
"

The bold text above would have prevented me from my original error. I don't
think guard conditions are an unusual pattern, but including one here
caused the program to silently fail.
Anyhow, no big deal, thought it would improve the exercise, but I
understand the desired for brevity, so I wouldn't argue if you think the
inclusion is too verbose.

Have a good one, and thanks for looking into it!
Jon

On Tue, Oct 13, 2015 at 4:34 PM, rakyll notifications@github.com wrote:

it would have helped me to be told that all characters in a reader should
be processed even if there is an error.

Is it? func (r rot13Reader) Read can return an error anytime and you can
don't have to consume all the characters from s if an error happens -- even
though I don't see where an error can happen in this particular exercise
during Read. Could you provide a snippet from your solution to make it a
bit clear?


Reply to this email directly or view it on GitHub
#12880 (comment).

@kytrinyx

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2015

There's an open issue about making the reader example less confusing: #11373

@jonburgin I'm having trouble figuring out what the code looked like that led you to getting a silent failure. Without a clear idea of what went wrong it's difficult to come up with a good explanation that would have helped you avoid it.

I'm pretty sure that having if count, err := otherReader.read(myByteBuffer); err { would have been a compile error. Do you recall if you said err != nil?

@jonburgin

This comment has been minimized.

Copy link
Author

commented Oct 14, 2015

Yes, err != nil

On Wed, Oct 14, 2015 at 2:00 PM, Katrina Owen notifications@github.com
wrote:

There's an open issue about making the reader example less confusing:
#11373 #11373

@jonburgin https://github.com/jonburgin I'm having trouble figuring out
what the code looked like that led you to getting a silent failure. Without
a clear idea of what went wrong it's difficult to come up with a good
explanation that would have helped you avoid it.

I'm pretty sure that having if count, err :=
otherReader.read(myByteBuffer); err { would have been a compile error. Do
you recall if you said err != nil?


Reply to this email directly or view it on GitHub
#12880 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.