<p>I've been using Go for a few months now (coming from Python), and I really do enjoy it. The <em>one</em> bugbear I have is the standard error idiom: </p>
<pre><code>thing, err := MakeThing()
if err != nil {
// handle error
}
</code></pre>
<p>I'll admit that most of my "handling" is just panicking on non-nil errors, but this pattern shows up so much, both in my own code and others. In fact, I don't think I've ever <em>not</em> seen it in a library.</p>
<p>Is there a better/cleaner way to handle errors or am I a petulant ex-Pythonista who's missing something crucial? Thanks for any and all advice.</p>
<hr/>**评论：**<br/><br/>pwforgetter: <pre><p>As a reader of code, I find it a delight that I don't have to worry about what exceptions might get thrown in function-calls, the flow you see is the flow that actually happens.</p></pre>BadMoonRosin: <pre><p>True, but I do wish that Go's <code>error</code> type contained a bit more metadata or logging capability. </p>
<p>When working with Go instead of Java or C#, one thing that I miss dearly is having detailed stacktrace information available. If I call a Java method, and it throws an <code>Exception</code> from somewhere within... the caller can inspect it, apply different handling based on its type, write it to the log file and automatically have a detailed stacktrace with code line numbers, etc.</p>
<p>None of that power exists in Go. There are no sub-categories of errors, there's only the single <code>error</code> type. And <code>error</code> has no idea what line it occurred on, or reflection-inserted stacktrace knowledge of any kind. It's just a dumb wrapper for a <code>string</code>.</p>
<p>Yeah, you CAN work around this by conventions. Always <code>log.Printf(err)</code> an error with detailed context info at the spot of occurrance, before returning it to the caller, etc. However, that's REALLY clunky, leads to a lot of double-logging, and even in the best-case scenario is still just lame compared to most over modern languages. Inexplicably, Go's <code>log</code> package doesn't support levels (e.g. debug, info, error) like every other logging framework out there today. It's nothing but <code>fmt</code> with a timestamp prefix.</p>
<p>I like the fact that Go encourages you to deal with errors when the occur, rather than "swallowing exceptions" or "always throwing exceptions" like other languages. However, let's not delude ourselves... Go's overall error-handling model is extremely primitive, and not in a good way.</p></pre>Sphagnum_affine: <pre><p>You can use annotated errors. </p>
<ul>
<li><a href="https://github.com/spacemonkeygo/errors">spacemonkeygo/errors</a></li>
<li><a href="https://github.com/juju/errors">juju/errors</a></li>
</ul>
<p>They allow attach position and/or message.</p></pre>mcvoid1: <pre><p>That whole "no sub-categories of errors" thing simply isn't true. Since errors are interfaces, you can have errors that include that information. Now it may not be built-in, but there's libraries out there which do just that.</p></pre>weberc2: <pre><p>More importantly, you can actually type assert or reflect to get that information.</p></pre>bkeroack: <pre><p>Every time you recommend somebody use reflect, a baby kitten dies.</p></pre>dilap: <pre><p>Definitely for errors you should just be doing type assertions. I don't think many kittens have died over the use of reflect in e.g. the standard json module, tho. :)</p></pre>weberc2: <pre><p>I don't know of another way to reliably get type information from an <code>error</code>. Do you?</p></pre>bkeroack: <pre><p>A type switch (to be safe against panics) or, if you're sure what concrete error type is returned, a bare type assertion.</p></pre>weberc2: <pre><p>A type assertion won't panic if you check the returned Boolean. </p></pre>hahainternet: <pre><blockquote>
<p>the caller can inspect it, apply different handling based on its type</p>
</blockquote>
<p>You should feel free to do this in Go too. Type switching can help easily distinguish errors imho.</p></pre>weberc2: <pre><p>This does break down when you have jackasses like me who use fmt.Errorf() for everything because creating my own error class is too verbose.</p></pre>hahainternet: <pre><p>I'm also guilty of that I must say.</p></pre>robertmeta: <pre><p>Now that you have identified the problem, step two is fixing it. :) </p></pre>weberc2: <pre><p>I don't know of any less-verbose solutions, but I'm open to suggestions.</p></pre>idevxy: <pre><p>There aren't any less-verbose solutions, but come on, it's 4 lines of code, and that's counting the closing brace.</p>
<pre><code>type MyError struct{}
func (MyError e) Error() string {
return "This is my error."
}
</code></pre>
<p>Then you can just <code>return MyError{}</code></p>
<p>Is it a big deal if you aren't writing a library? No. But it's very little effort for a nice boost in code cleanliness. That's what Go is all about: doing more with less.</p>
<p>Edit: mistakes</p></pre>Akkifokkusu: <pre><p>Your receiver syntax is wrong. Should be <code>e *MyError</code>. But why use pointers for an error type anyway? <code>e MyError</code> and <code>return MyError{}</code> are much more idiomatic, I think. The function should still be returning <code>error</code>, and the consumer can decide whether or not to use type assertion to dig into it.</p></pre>idevxy: <pre><p>Thanks for the correction. I haven't had the luxury of writing Go much lately. Stuck in Java Land. But why should it return <code>error</code> over <code>MyError</code> in this case, assuming it never returns a nested error that may be of different type? That seems like deferring information to runtime for no reason.</p></pre>dilap: <pre><p>It's a weird corner of the Go language.</p>
<p>So there are three possibilities</p>
<pre><code>func Foo() MyError
func Foo() *MyError
func Foo() error
</code></pre>
<p>Obviously the first doesn't work, since you can't return nil (i.e., there's no way to say "no error here").</p>
<p>You might think (2) would be good, but that's where you run into trouble -- assigning a nil MyError pointer to an error, does <em>not</em> give you a nil error!</p>
<pre><code>package main
import "fmt"
type GhostError struct{}
func (err *GhostError) Error() string { return "ghost error!" }
func Foo() *GhostError {
// a-ok...
return nil
}
func main() {
var err error
err = Foo()
if err != nil {
fmt.Printf("%s %#v\n", err.Error(), err)
} else {
fmt.Println("it's alright")
}
}
</code></pre>
<p>The above code prints "ghost error! (*main.GhostError)(nil)".</p>
<p>What's going on is that an interface value is two pointers: (value, class). For the interface to be nil, both the value and the class must be nil. But when you assign from a concrete pointer type to an interface value, the type is not nil.</p>
<p>To put it another way, a nil pointer can still be a perfectly good interface satisfier (as demonstrated by GhostError above).</p>
<p>This is really confusing the first time you encounter it, but is consistent and makes sense once you understand what's going on and how Go works.</p>
<p>It's definitely a sharp edge of the language though. (I wonder if Go linter's warn for this?)</p></pre>weberc2: <pre><p>Usually I'm embedding some context into the struct, so it's more like:</p>
<pre><code>type MyError struct {
Context string
}
func (MyError e) Error() string {
format := "An error happened. Here's the context: %s"
return fmt.Errorf(format, context)
}
</code></pre>
<p>I didn't say I disagree with your premise, and I often do it. But I really don't like breaking my train of thought to crank out that boilerplate, and it's easier to just <code>fmt.Errorf()</code> it and "come back to it later" (which rarely happens, unless I happen to be hitting that error and need more debugging context). Ideally something like this would be added to <code>go vet</code> or some other linter (maybe it already is?).</p>
<blockquote>
<p>That's what Go is all about: doing more with less.</p>
</blockquote>
<p>I don't much care about "what Go is all about"; I care about getting shit done quickly. Usually "doing more with less" serves that goal, but here it doesn't. Oh well.</p></pre>: <pre><p>[deleted]</p></pre>weberc2: <pre><p>How is that better than <code>fmt.Errorf()</code>?</p></pre>bkeroack: <pre><p>Errors can contain whatever data you want. It's just a single-method interface after all.</p>
<p>You (as the caller) <em>do</em> need to know what more-specific-error-type the method returns, but that's hardly unreasonable if you plan on inspecting the added data.</p></pre>idevxy: <pre><p>Further, there's no reason the func needs to return just <code>error</code>. You can have a signature like <code>func Foo() FooError</code> and effortlessly assign the return value to an <code>error</code> variable as long as it satisfies the interface.</p>
<p>That requires no more effort than knowing what the return value of the func is in the first place. This is Go's whole approach to error handling: Errors are just data, and error handling is just code. It's not special.</p></pre>dchapes: <pre><p>Don't do this. There are reasons (I wish I had the links handy) of why this is a bad idea. It's for those unlinked reasons that in <code>os</code> there are many functions documented as returning either <code>nil</code> or a <code>*os.PathError</code> but the signature is purposefully <code>error</code> and <strong>not</strong> <code>*os.PathError</code>.</p>
<p>Edit: from the <a href="https://golang.org/doc/faq#nil_error" rel="nofollow">FAQ</a>:</p>
<blockquote>
<p>It's a good idea for functions that return errors always to use the <code>error</code> type in their signature (as we did above) rather than a concrete type such as <code>*MyError</code>, to help guarantee the error is created correctly. As an example, <a href="https://golang.org/pkg/os/#Open" rel="nofollow"><code>os.Open</code></a> returns an <code>error</code> even though, if not <code>nil</code>, it's always of concrete type <a href="https://golang.org/pkg/os/#PathError" rel="nofollow"><code>*os.PathError</code></a>. </p>
</blockquote></pre>earthboundkid: <pre><p>Yeah, if I were designing Go 2.0, I'd change <code>error</code> to be an interface of <code>Error() string</code> <em>and</em> <code>Source() error</code> so that you can chain errors (the last error in the chain would just return <code>nil</code>).</p></pre>pure_x01: <pre><p>The problem is DRY though </p></pre>blogetry: <pre><p>This is true. Python's exceptions are a little too ephemeral, and Go's method of making errors actually part of the code makes things clearer.</p></pre>weberc2: <pre><p>Although in Go you still don't know if you're handling all errors correctly, since you don't know the set of all things that could implement the error interface. Sometimes I wonder if the idiom should have been <code>func() (OSError, IOError, ParseError)</code> instead of <code>func() error</code>.</p></pre>010a: <pre><p>Yes, instead we just get generic <code>error</code> strings with no identification as to what kind of errors a function might throw.</p>
<p><code>
public User getUser(String id) throws UserNotFoundException, ConnectionExcetion { }
</code></p>
<p>Versus</p>
<p><code>
func GetUser(id string) (User, error) { }
</code></p>
<p>As a reader of code, I find it a delight that I don't have to worry about what exceptions might get thrown in function calls. Except when the function's signature literally defines what exceptions will be thrown and the IDE takes care of the rest.</p>
<p>As a writer of code, I find it a delight that I have to read the actual source code of a Go function to determine the types of errors it is capable of returning so I know how to handle them. No, wait, that's not a delight; that's abhorrent. </p>
<p>I'm actually amazed at your opinion: its completely wrong in the case of any exception throwing language which requires (or at least allows) throwable exception types to be declared in the method signature, yet simultaneously ironically points out a glaring deficiency in Go. </p></pre>pwforgetter: <pre><p>I have more experience with python than with e.g. java, and the function doesn't list the possible exceptions. </p>
<p>If you need an IDE to tell you that:</p>
<pre><code>u = GetUser()
use(u)
</code></pre>
<p>might actually raise UserNotFoundException or ConnectionException and enver execute use(u), you have only won that you rely on a good ide instead of code that is readable on its own?</p>
<p>If I have to hover over every function call to see its signature, that's a lot slower than my eyes skipping over the error-cases but mentally understanding that it might abort there. (And I think it might force better error-messages, but that still requires discipline)</p></pre>010a: <pre><p>That's true. Python is the one exception (pun intended).</p>
<p>What's wrong with relying on tools to help you navigate code? Java is famous for it, but we do it with Go as well. What do you think Godoc is? The only difference is the magnitude to which the tools help you. </p>
<p>My opinion is that if I have to browse a library's source code to settle a deficiency in their API documentation or godoc, something is not right. There are ways of writing Go code so this is unnecessary, but its not idiomatic and very few libraries do this. </p>
<p>For example, I like writing functions like this:</p>
<pre><code>func GetUser(id string) (User, NotFoundError, CnctError) {}
</code></pre>
<p>That way it is explicit exactly which errors a function returns and errors <em>in</em> my error handling code can be caught at compile time. But quite often libraries design their APIs like this...</p>
<pre><code>// GetUser returns the user object and a UserNotFound
// error if the id doesn't exist or a CnctError if
// there is a problem with the database connection.
func GetUser(id string) (User, error) {}
</code></pre>
<p>Ok, we've got more information, but its in a doc string. If I'm using tooling like an IDE, it can't read that. And I'll probably need a type switch on the caller side to actually do something with that error, so there goes compile time safety. But at least I don't have to go digging through their source code. Until we get this:</p>
<pre><code>func GetUser(id string) (User, error) {}
</code></pre>
<p>Which is sadly the majority of libraries in Go. No information. Time to dig into this function on Github to figure out what it can return.</p></pre>dilap: <pre><p>A downside of listing all the possible error cases in your GetUser signature is if you decide to add another error case, you have to update all your function caller signatures. (Or, to put it another way, you break API compatability.)</p>
<p>Personally, I think something like this works well:</p>
<pre><code>// GetUser gets a user by id. If no user with that id exists, returns NotFoundError.
func GetUser(id UserId) error
</code></pre>
<p>And then you'd use it like this:</p>
<pre><code>user, err := GetUser(userId)
if err != nil {
if _, notFound := err.(NotFoundError); notFound {
// do some special stuff here
} else {
// generic case
}
}
</code></pre>
<p>Seems reasonable to me, but it's true that you're relying on the comments to tell you what's going on, rather than the type system.</p></pre>010a: <pre><p><a href="https://www.youtube.com/watch?v=ilcRS5eUpwk" rel="nofollow">Adding another error case <em>should</em> break API compatibility.</a> By adding another error case you are saying "something about the purpose of this function has changed so fundamentally that its capable of failing in a whole new way." By changing the function signature you can guarantee that every caller is now capable of handling the new failure case.</p>
<p>This is powerful and a huge upside to this method, not a downside. </p></pre>dilap: <pre><p>Doesn't make sense to me. The kinds of ways a function can fail is implementation detail; as a caller I don't really care why it failed, just that it did, most of the time.</p></pre>dericofilho: <pre><p><a href="https://blog.golang.org/errors-are-values">https://blog.golang.org/errors-are-values</a></p></pre>dasacc22: <pre><p>As of go1.6beta2</p>
<p>8029 lines of <code>err != nil</code></p>
<p>1792 of those lines are of <code>if err := [x]; err != nil {</code></p>
<p>5745 of those lines are of <code>if err != nil {</code></p>
<p>The remainder are either of form <code>if x.err != nil ...</code> or <code>if [string] != "[foo]" || err != nil {</code> or one of the above with a different name for err.</p>
<p>Basically you either start thinking about the implication of errors or you suffer the turmoil of typing out something you refuse to think about over and over. I don't recommend the latter.</p></pre>demizer: <pre><blockquote>
<p>Basically you either start thinking about the implication of errors or you suffer the turmoil of typing out something you refuse to think about over and over. I don't recommend the latter.</p>
</blockquote>
<p>When prototyping code, I used to do</p>
<pre><code>val, _ := func()
</code></pre>
<p>Eventually an error would occur and I would have to do fmt.Println() to find the problem only to discover I was ignoring the error and forgot.</p>
<p>Kinda of annoying that I have to think about all the errors that could ever happen, but it definitely does make for more well defined code.</p></pre>unitedcreatures: <pre><p>Use gometalinter to be sure, it emits warnings on ignored errors. </p></pre>mcvoid1: <pre><p>In some ways, Go's idiom is a bit more sophisticated than other languages in that it differentiates between everyday, run-of-the-mill errors and more exceptional ones, and only has the more exceptional ones break your control flow and have the potential to leave things a mess. Not being able to open a file is so common there's no reason to ditch your whole stack frame like when exceptions are thrown - just handle it up front and leave no questions as to whether or not something else still needs to be cleaned up.</p>
<p>If you're eating at a table and drop something on the table, you just clean it up right then and there - you don't need to flip the whole table over and then get a mop to clean up the floor.</p></pre>mixedCase_: <pre><p>That's correct form. Go was designed to create robust software, this way you become more aware of failure points and forces you to handle them or pass them along.</p>
<p>Exceptions (unless they're checked ones) make you automatically pass them along unless explicitly handled. Which makes it more likely to miss errors you'd like to handle in a specific way. Hell, most of the time we don't even know if what we're calling is even able to blow up much less how they could!</p>
<p>Also, you can also save a line by doing:</p>
<pre><code>if thing, err := MakeThing(); err != nil {
// handle error
}
</code></pre>
<p>I try to avoid it unless the situation is very simple since it makes for slightly harder to read code and that's what Go fiercely tries to avoid.</p>
<p>Also, PLEASE do not use panic for recoverable errors. Just return an error.</p></pre>random_testaccount: <pre><blockquote>
<p>Go ... forces you to handle them or pass them along. </p>
</blockquote>
<p>You're not forced to handle errors: </p>
<pre><code>func foo(i int) error {
if i == 0 {
return errors.New("I like errors")
}
fmt.Printf("Hello %d\n", i)
return nil
}
func main() {
foo(1)
foo(0) // Oh no, I forgot foo can return an error!
foo(2)
}
</code></pre>
<p>When you need to perform foo3, for which you need data from foo2, for which you need data from foo1, every step of which may return a value or an error, and in the case of an error with each step, you need to do bar and then exit, don't you sometimes wish you had a try .. catch .. finally type construct? </p>
<p>Yes, I know the go way is perfectly workable, but is it always the most elegant? Apple decided to move to a try .. catch syntax with swift 2.0 after starting with a go-like approach. </p></pre>carbocation: <pre><p>I do wish that every return value had to be handled, even with just <code>_</code> to make it explicit that it was being ignored.</p></pre>mixedCase_: <pre><p>You know, that's a really good argument for the compiler to throw a warning or an error even, when you ignore return values via just calling the function.</p>
<p>My personal experience is that I never call a function without assigning the value to something (even if it's underscore), and if I'm going to do so it's because I've weighted the options and am going to look both ways before crossing the street. It's like a personal bad practice to do otherwise, but I assume plenty of people don't do the same.</p></pre>wehavetobesmarter: <pre><p>Would be better in this case to return a (bool,error) since you are interested in the side effect.
In some cases, a wrapper that panics on error could be appropriate.</p></pre>arnaldomf: <pre><p>When you do this kind of error checking:</p>
<pre><code>if thing, err := Makething(); err != nil {
...
}
</code></pre>
<p><strong>thing</strong> is created in a new scope, so it is not usable outside of the if/else, even if it was declared before.</p></pre>ihsw: <pre><p>You sure about that? I do <code>var thing thingStruct</code> prior to those if statements all the time purely because I noticed they weren't carrying over to outside the if block's scope.</p></pre>carbocation: <pre><p>If you want <code>thing</code> available outside of the <code>if/else</code> scope, then you need to declare both <code>thing</code> and <code>err</code> beforehand and use <code>=</code> rather than <code>:=</code>.</p></pre>arnaldomf: <pre><p>Sorry, i meant that if you use the symbol <strong>:=</strong> as in</p>
<p>if thing, err := Makething(); err != nil</p>
<p>you will be declaring a new variable called thing in the if/else socpe, so the value received from Makething will not be persisted in the <strong>thing</strong> declared before.</p></pre>ihsw: <pre><p>Ah, very true.</p></pre>blogetry: <pre><p>Yes, this is what I'm learning so far. </p>
<p>The programs I'm writing are small, run-once affairs (my current one is a blog generator), so they die <em>immediately</em> upon seeing a non-nil error. I've not yet had a situation where I've actually had to "handle" an error.</p>
<p>I thought I knew about the <code>if ...; err != nil</code> trick, but I must have forgotten. And yes, I'm using log functions to print and die now, instead of panicking. Thanks!</p></pre>cathalgarvey: <pre><p>As a fellow Pythonista it's common at first to think "I'll just panic and recover!" but the Go order of events is to unwind first and look for recovers later, so it's actually nowhere near Python's raise/except system.</p>
<p>I pretty much only use panic to kill an application with a stack trace. The defer/recover thing is just not how I reason about code if I can help it.</p></pre>DualRearWheels: <pre><p>I use defer/recover only at top level of each goroutine to collect and report errors before terminating (or restarting routine). Makes program more robust.</p>
<p>Compared to Python, D and other exception languages, I find Go's error approach more simpler and reliable. More than once I forgot try/catch block that caused me a lot of grief. In Go that is impossible, even with error default returning value (zero usually) can cover most cases.</p></pre>blogetry: <pre><p>Is defer useful? It seems strange to defer a statement when I could just put it at the end of a function.</p></pre>DualRearWheels: <pre><p>It is, when you have multiple exit points (returns or even panic) or complex work flow it would be much harder and error prone other way. And it is much more readable to group defer code at function start or grouped with relevant code (open file, deferr close file etc.).</p></pre>blogetry: <pre><p>Hmm, I guess it does make sense to bundle all your open/close statements into one chunk at the beginning of a function, before entering an actual workflow.</p></pre>tmornini: <pre><p>I prefer Ruby's ensure.</p>
<p>I'd be shocked if Go 2 doesn't implement some form of try/catch/throw.</p></pre>freebullets: <pre><p>AFAIK, deferred statements are always called before exiting the function. So if I put an <code>if x { return }</code> in the middle of the function, my deferred statement will be called, whereas if it was at the end of the block it wouldn't. I believe it also executes before panics.</p></pre>blogetry: <pre><p>Executing before panics makes sense actually, because then you could use them as a mandatory cleanup action (<code>.Close()</code>, etc) that happens regardless of any panics. Thanks.</p></pre>kurin: <pre><p>Deferred statements aren't called if another goroutine panics, or if any goroutine calls os.Exit.</p></pre>blogetry: <pre><p>You're right, the temptation to just panic and let the error bubble up to a more recoverable place is very strong. (As is the temptation to write my variables in <code>snake_case</code>, but alas.)</p></pre>mellowdrifter: <pre><p>Personally I hate negatives. I would much prefer 'if err' - handle error. </p></pre>daniu: <pre><blockquote>
<p>Personally I hate negatives</p>
</blockquote>
<p>What's wrong with</p>
<pre><code>if !invalid != false { ... }
</code></pre>
<p>? ;)</p>
<p>Seriously though, I prefer to have my code handle the most common, "normal", cases first, so the non-error one. Increases readability imo.</p></pre>blogetry: <pre><p>Yeah, <code>if err != nil</code> is quite readable and it states exactly what you're doing. Besides, it's literally everywhere in existing Go code. </p>
<p>Not saying <code>if err != nil</code> in Go is like not calling the self argument<code>self</code> in Python.</p></pre>rco8786: <pre><p>Both the best and the worst. The language maintainers sticking to their guns as if err != nil being somehow elegant is hogwash.</p>
<p>The standard argument is "I don't have to worry about what exceptions might get thrown" or some such.</p>
<p>Go look at any major Go lib(Docker, InfluxDB, Go itself, whatever) you'll see hundreds or thousands of:</p>
<pre><code>if err != nil
return err
</code></pre>
<p>All you're doing it passing the error back up the stack, just like an exception. And at some point you write an error handler that logs it and shows a message to the user, just like an exception. The only difference is that you have to do it manually, and without error types. Joy.</p></pre>oefig: <pre><blockquote>
<p>All you're doing it passing the error back up the stack, just like an exception. And at some point you write an error handler that logs it and shows a message to the user, just like an exception.</p>
</blockquote>
<p>The idea of handling errors in-line is so you can try to recover from them when they happen. With exceptions it's too easy to just handle all exceptions the same way or ignore them completely.</p></pre>rco8786: <pre><p>I know what the <em>idea</em> is. But the <em>reality</em> is that it just doesn't happen. Like I said, check out error handling in basically any Go library. They're all smattered with returning the error to the caller up to some main error handling site. </p>
<p>How many errors can you really recover from in line? Not many. The vast majority of the time theyre logged and an error message is shown to the user. </p></pre>andreynering: <pre><p>I don't know if it is the best alternative, but you could write functions to abstract handling the errors:</p>
<pre><code>package main
func checkErr(err error) {
if err != nil {
// do something:
// panic it or write in the log, etc.
}
}
func main() {
foo, err := doSomething()
checkErr(err)
}
</code></pre></pre>favadi: <pre><p>Compare:</p>
<pre><code>foo, err := doSomething()
checkErr(err)
</code></pre>
<p>with</p>
<pre><code>foo, err := doSomething()
if err != nil {
}
</code></pre>
<p>I'll say the latter one is more readable.</p></pre>d_rudy: <pre><p>The pattern I use in my web app is something like this:</p>
<pre><code> func handleError(err error, w http.ResponseWriter) {
switch err.(type) {
case ErrNotFound:
http.Error(w, err.Error(), http.StatusNotFound)
default:
http.Error(w, err.Error(), http.StatusInternalServerError)
}
}
http.HandleFunc("/posts", func(w http.ResponseWriter, r *http.Request) {
posts, err := getPosts()
if err != nil {
handleError(err, w)
return
}
// do something with the posts
}
</code></pre>
<p>The advantage being that I have a few error types that will all respond with the same http error code, and then if I don't have a special case, then it should probably return a 500. I could do it inline in the http handler, but after a while I would lose consistency of what type of errors were supposed to return what kind of http error codes. Now I can guarantee some sort of consistency, and I think the benefit outweighs the fact that I'm using a type switch.</p></pre>daddyc00l: <pre><p>maybe you should be calling the error handler httpErrorHandler ?</p></pre>blogetry: <pre><p>It's also better because unless you're just passing off errors to be printed and panicked, you need the context to actually handle the error. If you pass an error to a separate function, you lose all the context you need to resolve the error.</p></pre>andreynering: <pre><p>You are right, when you <em>can</em> handle the error (And when you can, you also should).</p>
<p>In some cases the only thing you can do is log and panic (or return error 500 if it is a web app, etc.).</p></pre>headzoo: <pre><blockquote>
<p>In some cases the only thing you can do is log and panic</p>
</blockquote>
<p>Sure, but at the top level of your app. Panics should only be triggered in a few places in your code. Libraries, functions, methods, etc shouldn't panic. If they can't handle the error it should be passed up the stack.</p>
<p>The checkErr() function is really only useful in the main() function, and there shouldn't be so many error checks in main() that a convenience function is even warranted.</p></pre>andreynering: <pre><blockquote>
<p>Panics should only be triggered in a few places in your code.</p>
</blockquote>
<p>Agree.</p>
<p>But panicing is not the only thing you can do inside the function. You can have one function that panic, other that return error 500, other that writes a warning in the log, etc. Whatever you want, actually. The ideia is reducing duplication of code.</p>
<p>Sure there are cases you have to handle it youself. I also agree it should be used at high level. In low level functions it is better to just return the error to the caller.</p></pre>sriramalka: <pre><p>Have you seen Rob Pike's "errors are values" talk? There are ways of structuring your code so that every alternate line is not "if err ...".</p></pre>gbitten: <pre><p>I love the way how Go handles errors for its simplicity. BTW, another related cool feature are the <a href="http://blog.golang.org/defer-panic-and-recover" rel="nofollow">Defer, Panic, and Recover functions</a>. I use them extensively, not only for errors, but as a way to exit quickly of a series of nested functions. The below web application example, I use them to print errors and to redirect to other url. </p>
<pre><code>package main
import "net/http"
func CheckError(err error) {
if err != nil {
panic(err)
}
}
func Redirect(url string) {
panic(url)
}
func handler(w http.ResponseWriter, r *http.Request) {
defer func() {
if rec := recover(); rec != nil {
switch rec.(type) {
case string:
url := rec.(string)
w.Header().Set("Location", url)
w.WriteHeader(http.StatusFound)
case error:
err := rec.(error)
http.Error(w, err.Error(), http.StatusInternalServerError)
}
}
}()
if user_not_logged() {
Redirect("http://site.com/login")
}
err := do_something()
CheckError(err)
do_more_stuff()
}
func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil)
}
</code></pre></pre>warmans: <pre><p>That's the main pattern. One other is to create methods like: </p>
<pre><code>func MustMakeThing()
</code></pre>
<p>which will panic or log.Fatal if they fail. The Must prefix indicates it has to succeed or it will panic (used in the regex package for example).</p>
<p>Note that if you use:</p>
<pre><code>if thing, err := MakeThing(); err != nil {
// handle error
}
</code></pre>
<p>the thing variable is only available within the braces, so it's mainly useful when the method only returns and error and nothing else.</p></pre>andreynering: <pre><p>I like this pattern, specially for things like a broken regex, that is a must fix.</p></pre>random314: <pre><p>I'm pretty sure half of my code consists of that check... That included unit tests.</p></pre>doki_pen: <pre><p>Passing the error to the caller::</p>
<pre><code> func myfunc() (err error) {
val, err := errorprone()
if err != nil {
return
}
// do something with val
}
</code></pre></pre>yeah-ok: <pre><p>Hmm, what about this full on simple function:</p>
<blockquote>
<p>thing, err := MakeThing()</p>
<p>PanicOnError(err);</p>
</blockquote>
<p>Makes 3 lines of code into one and doesn't obscure the code much as far as I can see.</p></pre>skelterjohn: <pre><p>On the other hand, your program immediately crashes. So it's got that going against.</p></pre>yeah-ok: <pre><p>Point being that it could be:</p>
<blockquote>
<p>RecoverOnError(err,functiontorevocerwith())</p>
</blockquote>
<p>Or whatever you please, all the same no conditional statement need to be written out in the middle of one's code if it's not wanted.</p></pre>skelterjohn: <pre><p>You just have all the error handling hidden away, easily forgotten about when you add new potential errors, and if you do it wrong panics that you <em>don't</em> intend will be suppressed.</p>
<p>Panics are not exceptions, and shouldn't be used as such. There are too many leaks in the abstraction.</p></pre>tucnak: <pre><p>Well, it's quite disgusting tbh. Since it requires nothing but understanding of conditional statements, which is the most popular PL construct, it's quite readable. I can't understand why Go advocates keep on defending it and trying to pull some daft points off... you know, all you need to say is "type system's weak, the language considered awfully small, so C-style error handling is the best we could get by design. it's not ideal, but works good for what Go is for". Go advocates keep on saying that while error is a trivial interface, errors are values and therefore, incredibly powerful, but that's completely false. Type system of the language and the actual error handling approach absolutely fails when it comes down to actually handling them. All we do is <code>return err</code> all the way through stack and possibly log it somewhere (usually, even without any details — good luck in debugging). Wanna see a stack trace? Context? You just can't, the language is created for fresh-out-of-school Googlers, not capable of understanding a language with abstractions more sophisticated than trait.</p>
<p>Answering your question: No, <code>if err != nil</code> is definitely not the best idiom for error handling. Imo, Either monad does significantly better. In fact, if you think about it, it's not logical to return errors at all. There must be a distinct layer for error handling, since error has nothing to do with the value returned by some function, it's just what could possibly happen.</p></pre>daniu: <pre><p>I think you're entirely right. There seems to be that great feeling of satisfaction that "an error is a value" - when conceptually it just isn't. An error is a circumstance that invalidates a result.</p>
<p>And even within Go, it's not really consistent - when a function returns "multiple values" (result, error), either the result is valid, or the error is set - so it really just returns one value.</p>
<p>That said, it's not that I'm particularly offended or anything by Go's error concept - errors have always been problematic to design into a language; C's global error, Java's RuntimeExceptions that don't have to be declared so there's still ways to run into undeclared problems...</p></pre>
