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
Open

tour:rot13Reader hint #12880

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

Comments

@jonburgin
Copy link

@jonburgin jonburgin 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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 8, 2015

@rakyll
Copy link
Contributor

@rakyll rakyll 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
Copy link
Author

@jonburgin jonburgin 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
Copy link
Contributor

@kytrinyx kytrinyx 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
Copy link
Author

@jonburgin jonburgin 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.