Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

On Thursday, 7 July 2016 01:45:17 UTC+2, Dave Cheney wrote: > > Why panic, the method returns an error value that can be used to tell the > caller they made a mistake. There's a subtle line there and Go's philosophy is not firmly on one side of it. I think the key phrase would have to be: "this

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

go's panic correspond, if anything, to unchecked exceptions in Java and they should be treated as such, i.e. they should never be caught and only be thrown on a clear programmer error. And once you restrict yourself to checked exceptions, there really isn't an advantage of a try-catch over an if er

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

On Thu, Jul 7, 2016 at 9:44 AM, Dave Cheney wrote: > Hi Martin, > > Go doesn't have exceptions, it really doesn't. Some people like to pretend > that panic/recover are exceptions, but really they are not [1]. Yes, sure, they're called something else :-) But they behavior matches what you get with

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Hi Martin, Go doesn't have exceptions, it really doesn't. Some people like to pretend that panic/recover are exceptions, but really they are not [1]. Thanks Dave 1. https://golang.org/doc/faq#exceptions On Thursday, 7 July 2016 17:36:30 UTC+10, Martin Geisler wrote: > > Hi Dave > > On Thu, J

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Hi Dave On Thu, Jul 7, 2016 at 2:08 AM, Dave Cheney wrote: > If this function panic'd then people who raise issues to make it not panic, > or they would work around it with recover(), both of which would be in less > tested code paths. As a newcomer to Go, it's fun to me that you call using reco

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

If this function panic'd then people who raise issues to make it not panic, or they would work around it with recover(), both of which would be in less tested code paths. If this function accepted any integer for level and silently clamped it to a reasonable minimum or maximum value, then peopl

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

In this particular case, the only possible error is that the compression level is invalid. The documentation says that the error will be nil if the level is valid. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group a

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Why panic, the method returns an error value that can be used to tell the caller they made a mistake. -- 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

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Yes, panic would probably have been a better choice there. In the API cleanups leading up to Go 1, the team removed some of the error returns from the NewWriter functions in the compress/* packages (https://codereview.appspot.com/5639057), but maybe it would have been good to go farther. Andy

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

What about gzip.NewWriterLevel(w, level)? It returns an error if level is invalid. Shouldn’t it panic instead if the level is invalid? > On Jun 30, 2016, at 12:30 PM, Andy Balholm wrote: > > When a function is used incorrectly, a panic is appropriate. If the count > comes from an untrusted sou

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Good point integer overflow. Thanks! On Thursday, June 30, 2016 at 10:30:46 AM UTC-6, Andy Balholm wrote: > > When a function is used incorrectly, a panic is appropriate. If the count > comes from an untrusted source, the caller should check that it is > non-negati!e (and not too large) before c

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Ah yes, operations that can and will fail are different than those that fail because of a logic error. Thanks! On Thursday, June 30, 2016 at 10:27:18 AM UTC-6, Ian Lance Taylor wrote: > > On Thu, Jun 30, 2016 at 9:17 AM, Michael Whatcott > wrote: > > The blog post on error handling in go estab

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

When a function is used incorrectly, a panic is appropriate. If the count comes from an untrusted source, the caller should check that it is non-negative (and not too large) before calling Repeat, rather than checking an error afterward. Using a uint would actually be worse, since uint(int(-1))

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

On Thu, Jun 30, 2016 at 9:17 AM, Michael Whatcott 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

[go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

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