On Thu, Jun 30, 2016 at 9:17 AM, Michael Whatcott <mdwhatc...@gmail.com> wrote:
> The blog post on error handling in go establishes the following guideline:
>
>> In Go, error handling is important. The language's design and conventions
>> encourage you to explicitly check for errors where they occur (as distinct
>> from the convention in other languages of throwing exceptions and sometimes
>> catching them).
>
> Here's the implementation of strings.Repeat:
>
> // Repeat returns a new string consisting of count copies of the string
> s.
> func Repeat(s string, count int) string {
> b := make([]byte, len(s)*count)
> bp := copy(b, s)
> for bp < len(b) {
> copy(b[bp:], b[:bp])
> bp *= 2
> }
> return string(b)
> }
>
> Notice that when a negative value is supplied for the count argument, panic
> ensues because it attempts to make a byte slice of negative length:
>
> package main
>
> import "strings"
>
> func main() {
> strings.Repeat("panic!", -1)
> }
>
> Output:
>
> panic: runtime error: makeslice: len out of range
>
>
> Of course, returning two values from strings.Repeat would make it less
> convenient to use, but it does reflect what can happen if the value
> calculated for the count argument is negative for whatever reason.
>
> Another option would have been to use a uint for the count argument but that
> would introduce a different kind of inconvenience for both the caller and
> the implementation.
>
> I am fully aware of the go compatibility promise and I'm not proposing a
> change to strings.Repeat. I can code a custom Repeat function for my own
> purposes. The purpose of the question is to better understand error handling
> in go.
>
> So, considering the recommendation from the go blog to return errors rather
> than panic, should strings.Repeat (and other such functions) always be
> implemented with more rigorous error handling? Or, should it always the
> caller's job to validate inputs that might cause a panic if otherwise
> unchecked?
There are many cases in the standard library where a function will
panic on invalid input. People can disagree about what is best, but
personally I think this is OK. It's essential that functions behave
predictably on invalid input, but if the input is completely invalid a
panic is OK. It points the programmer directly at the problem. It's
not fundamentally different from the fact that a[-1] will panic.
Returning an error instead of a panic pushes error handling onto all
programs for a case that should happen in no programs.
Of course it's essential to only panic on cases that can never happen
in a valid program. I/O operations, for just one example, can fail in
many ways, and it would never be appropriate to panic on an I/O error.
Ian
--
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.
