The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
|
Ch 1
Math operations and comparisons |
In the book it's written like this: "<= tests whether the second value is less than or equal to the first, and >= tests whether the second value is greater than or equal to the first."
I guess it's the other way around, so should be:
">= tests whether the second value is less than or equal to the first, and <= tests whether the second value is greater than or equal to the first."
Note from the Author or Editor: On page 13, "<= tests whether the second value is less than or equal to the first, and >= tests whether the second value is greater than or equal to the first" should be changed to "<= tests whether the first value is less than or equal to the second, and >= tests whether the first value is greater than or equal to the second".
|
Balazs Jakab |
Apr 16, 2019 |
Jul 26, 2019 |
|
Ch 6
Slices and zero values |
The output and code fragment do not match.
Code:
intSlice = append(intSlice, 27)
fmt.Printf("intSlice: %#v\n", intSlice)
Output:
stringSlice: []string{27}
The output should be:
intSlice: []int{27}
Note from the Author or Editor: Confirmed. Output text should be updated as described in submission.
|
Balazs Jakab |
Apr 21, 2019 |
Jul 26, 2019 |
|
Ch 8
Pass large structs using pointers |
This text most probably contains a typo:
"Since this is already a struct, remove the address-of operator"
I guess it should be something like:
"Since this is already a pointer, remove the address-of operator"
Note from the Author or Editor: Confirmed. Annotation should be updated as described in submission.
|
Balazs Jakab |
Apr 21, 2019 |
Jul 26, 2019 |
|
Ch 8
Struct field names must be capitalized to be exported |
The text contains fields that are not - yet - added to the scruct:
"It wouldn’t make sense to be able to access the subscription rate from other packages, but not the name or address."
Maybe should refer to "active" field instead:
"It wouldn’t make sense to be able to access the subscription rate from other packages, but not the name or active."
Note from the Author or Editor: Change this sentence:
It wouldn’t make sense to be able to access the subscription rate from other packages, but not the name or address.
To this:
It wouldn’t make sense to be able to access the subscription rate from other packages, but not the name or active status.
|
Balazs Jakab |
Apr 21, 2019 |
Jul 26, 2019 |
|
Ch 14
We’ve introduced a bug! |
Under the image of a construction worker there are two "checks" with text like:
"For []slice{"apple", "orange", "pear"}, JoinWithCommas should return "apple, orange, and pear""
I guess it should be []string{...} instead in both of them.
Note from the Author or Editor: Change all occurrences in chapter of "[]slice" to "[]string" (without quotes). Affected pages are 405, 409, and 412.
|
Balazs Jakab |
Apr 23, 2019 |
Jul 26, 2019 |
Printed, PDF, |
Page ?
2nd paragraph |
This is a trivial missing word problem.
"It does using two separate for loops" ->
"It does it using two separate for loops"
(I'm sorry I couldn't supply a page number but they don't appear with the Safari Online version I'm reading).
Note from the Author or Editor: Page 223. Please change "It does using two separate for loops..." to "It does this using two separate for loops..."
|
Jon Forrest |
Oct 25, 2019 |
|
|
1st paragraph in chapter “8 structs” (page number unknown, Safari Books Online does not display page numbers) |
The phrase “Think of mailing addresses, where you have to mix street names (strings) with postal codes (integers).” recommends bad practices: Postal codes should not be represented by integers, but by strings (of digits).
First of all, in many countries (including e.g. the U.S.) postal codes may contain leading zeros. In such countries a postal code 01234 is not at all the same as 1234.
More importantly, it is semantically wrong: Integers are intended to represent entities with which calculations can be done. It does not make sense to add or multiply postal codes. Postal codes are just strings that happen to consist of digits, but their numeric value has no meaning.
Note from the Author or Editor: In the Chapter 8 introduction, change "Think of mailing addresses, where you have to mix street names (strings) with postal codes (integers)" to "Think of billing receipts, where you have to mix item names (strings) with quantities (integers)".
|
Martin Dickopp |
Oct 30, 2018 |
Jul 26, 2019 |
|
Ch 11
Under "A method parameter that can only accept one type" |
https://imgur.com/a/pDK4iIE
Note from the Author or Editor: The annotation "TapePlayer also has a Play method with a string parameter" should be changed to "TapeRecorder also has a Play method with a string parameter". The annotation "TapePlayer also has a Stop method with no parameters" should be changed to "TapeRecorder also has a Stop method with no parameters".
|
Mahmudul Haque |
Jan 27, 2019 |
Jul 26, 2019 |
|
Page 241
Bottom line |
The "Code Magnets" exercise on page 241 ends with "Answers on page 241". This should read "Answers on page 262".
Note from the Author or Editor: Page number should be corrected as described in the submission: 'The "Code Magnets" exercise on page 241 ends with "Answers on page 241". This should read "Answers on page 262".'
|
Anonymous |
Jun 24, 2021 |
|