Go error handling(code.ohloh.net)
code.ohloh.net
Go error handling
https://code.ohloh.net/search?s=%22if%20err%20!%3D%20nil%22&pp=0&fe=go&mp=1&ml=0&me=1&md=1&ff=1&filterChecked=true
15 comments
Panic is not exit. http://golang.org/pkg/os/#Exit is exit
Panic is throw. Recover is an isomorphism for catch.
For the most part. You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.)
Panic is throw. Recover is an isomorphism for catch.
For the most part. You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.)
> You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.)
I'm not sure I udnerstand what you mean. I can write: fmt.Fprint(os.Stdout, "Something\n")
This returns an error, which I silently discard. Did you mean something else?
I'm not sure I udnerstand what you mean. I can write: fmt.Fprint(os.Stdout, "Something\n")
This returns an error, which I silently discard. Did you mean something else?
fmt.Fprint(os.Stdout, "Something\n")
By itself isn't a valid statement. You try to compile that and you'll get an error saying unused return value. So you'll try:
err := fmt.Fprint(os.Stdout, "Something\n")
and you could ignore err, but then you'll get a compiler saying err is defined but never used. So you can be like NAH I'm just trying to muck stuff up so I"m going to do this.
_ = fmt.Fprint(os.Stdout, "Something\n")
Which is explicitly discarding the error much like:
try{ fmt.Fprint(os.Stdout, "Something\n") }catch(Throwable t){}
By itself isn't a valid statement. You try to compile that and you'll get an error saying unused return value. So you'll try:
err := fmt.Fprint(os.Stdout, "Something\n")
and you could ignore err, but then you'll get a compiler saying err is defined but never used. So you can be like NAH I'm just trying to muck stuff up so I"m going to do this.
_ = fmt.Fprint(os.Stdout, "Something\n")
Which is explicitly discarding the error much like:
try{ fmt.Fprint(os.Stdout, "Something\n") }catch(Throwable t){}
I'm sorry, but that's not true: http://play.golang.org/p/PiMXQkKOef
So it appears you're right. For things for which you don't care about any value returned this is the case. The reason I haven't run into this is for the most part things that can error, they also return a value that matters. You can't use the return value without doing something with the error.
http://play.golang.org/p/yreUbxx5Vv
So it appears that there is a loophole for things that can error and purely used for side effects.
http://play.golang.org/p/yreUbxx5Vv
So it appears that there is a loophole for things that can error and purely used for side effects.
This is true, you can drop all return values. However, a lot of functions return a value and an error. If you want to access the value, you need to assign the error to something too. And if you don't then use that error, the compiler will complain about it.
For simply dropping all return values on the ground, there are linters that will complain for you: https://github.com/kisielk/errcheck
For simply dropping all return values on the ground, there are linters that will complain for you: https://github.com/kisielk/errcheck
"In order to ignore error codes in go, you must do so explicitly". - FTFY
Yeah. The only caveat I'd give is a bit of a stretch. Not explicitly error handling, but you can lookup maps as:
j := m["root"]
or
j, ok := m["root"]
Again, this tangential to the subject at hand. But this is the main reason I qualify that statement.
j := m["root"]
or
j, ok := m["root"]
Again, this tangential to the subject at hand. But this is the main reason I qualify that statement.
That's a very good point, actually. It's tricky, because always requiring the latter format is burdensome, especially if the zero value of the map is an ok value for you...
So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged.
There are linters which will tell you when you forget to check an error code.
You say that unhandled errors can cause data corruption, but what about improperly cleaning up resources? That happens all the time... you have your data partially written to disk and something throws an exception, if you don't have your cleanup code in a try/finally, then bam, corrupt data. That's a lot more likely with the mindset of generally just letting exceptions fly.
There are linters which will tell you when you forget to check an error code.
You say that unhandled errors can cause data corruption, but what about improperly cleaning up resources? That happens all the time... you have your data partially written to disk and something throws an exception, if you don't have your cleanup code in a try/finally, then bam, corrupt data. That's a lot more likely with the mindset of generally just letting exceptions fly.
> So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged.
I thought it was officially only discouraged across module boundaries -- e.g., library code shouldn't let panics "escape".
I thought it was officially only discouraged across module boundaries -- e.g., library code shouldn't let panics "escape".
>> but what about improperly cleaning up resources?
What about it? Are you saying that error return values somehow force programmers to properly cleanup resources?
>> That happens all the time...
How are you quantifying that? I write code in exception bearing languages all the time and never have this problem. Why would you begin a partial write and then call some code that would likely produce errors or exceptions? That sounds like a recipe for corrupt data no matter the style of error catching. A better way would be to use a method of writing that is basically atomic.
A lot of your arguments in this thread sound a bit contrived.
What about it? Are you saying that error return values somehow force programmers to properly cleanup resources?
>> That happens all the time...
How are you quantifying that? I write code in exception bearing languages all the time and never have this problem. Why would you begin a partial write and then call some code that would likely produce errors or exceptions? That sounds like a recipe for corrupt data no matter the style of error catching. A better way would be to use a method of writing that is basically atomic.
A lot of your arguments in this thread sound a bit contrived.
I'm saying that most people who complain about Go's verbosity do not take resource cleanup into consideration. They think they can let exceptions fly without any try/catch or try/finally and everything will be fine, which is obviously untrue.
Sorry, what I meant by "happens all the time" is that there are often cases where you need cleanup code that gets called if the function doesn't exit cleanly.
There's very often no atomic way to perform a series of actions. Please keep in mind, I was being very vague on purpose. There is almost always a list of actions that you want to either all succeed, or else you need to do some cleanup if later ones fail.
In code with exceptions, you don't always know what can throw. Unless you're using java code that has been written with strict checked exceptions, you have to assume any external function you call can throw. Even if it doesn't now, it might when Bob from the next team over decides that now it should.
I really don't think it's at all contrived. I'm not saying you can't write this code with exceptions, I'm saying it's harder than it needs to be, and it's at least as verbose as Go, if you're doing all the right things with your try/catch/finally's.
Sorry, what I meant by "happens all the time" is that there are often cases where you need cleanup code that gets called if the function doesn't exit cleanly.
There's very often no atomic way to perform a series of actions. Please keep in mind, I was being very vague on purpose. There is almost always a list of actions that you want to either all succeed, or else you need to do some cleanup if later ones fail.
In code with exceptions, you don't always know what can throw. Unless you're using java code that has been written with strict checked exceptions, you have to assume any external function you call can throw. Even if it doesn't now, it might when Bob from the next team over decides that now it should.
I really don't think it's at all contrived. I'm not saying you can't write this code with exceptions, I'm saying it's harder than it needs to be, and it's at least as verbose as Go, if you're doing all the right things with your try/catch/finally's.
Here's why Go's errors are better than exceptions:
Multithreaded environments make exception handling next to impossible to do correctly. The stack trace only shows a single thread which is often useless without more context. Exceptions are per-thread, so handling has to be per-thread.
Exceptions make the control flow of your program completely obscure. Any line that calls out to another function can cause this function to exit. If you're not wrapping every function call in a try/finally, you're probably doing it wrong (at which point it's even more verbose than go's error returns).
Errors in Go aren't special. They're just values returned from a function. You have the whole language at your disposal to deal with them.
I can write this in Go, and it's perfectly safe:
The reason people think Go exception handling is verbose is because they aren't really handling errors in their own code. Go makes it easy to handle errors in the right way.
Multithreaded environments make exception handling next to impossible to do correctly. The stack trace only shows a single thread which is often useless without more context. Exceptions are per-thread, so handling has to be per-thread.
Exceptions make the control flow of your program completely obscure. Any line that calls out to another function can cause this function to exit. If you're not wrapping every function call in a try/finally, you're probably doing it wrong (at which point it's even more verbose than go's error returns).
Errors in Go aren't special. They're just values returned from a function. You have the whole language at your disposal to deal with them.
I can write this in Go, and it's perfectly safe:
f, err := os.Open(filename)
if err != nil {
return fmt.Errorf("Failed to open config file: %s", err)
}
err = callFunctionThatMightErrorOut()
if err != nil {
// handle err
}
f.Close()
File f
try {
try {
f = os.Open(filename)
}
catch(Exception e) {
throw new Exception(string.Format("Failed to open config file: %s", e.Message))
}
try {
callFunctionThatMightErrorOut()
}
catch(Exception e) {
// handle error
}
}
finally {
if f != nil {
f.Close()
}
}
The reason people think Go exception handling is verbose is because they aren't really handling errors in their own code. Go makes it easy to handle errors in the right way.
Your exception code ignores RAII, which is about the best argument for exceptions. The file should be closed as soon as the function returns for any reason, which (with a sensible design and properly implemented destructors) will be as soon as the function returns for any reason, meaning the outside try-finally is entirely unnecessary and the file is guaranteed freed even if you have multiple returns.
Golang has defer. http://golang.org/doc/effective_go.html#defer
That's what grandparent post should have been using.
That's what grandparent post should have been using.
f, err := os.Open(filename)
if err != nil {
return fmt.Errorf("Failed to open config file: %s", err)
}
defer f.Close() // This is going to be always executed when leaving this function
err = callFunctionThatMightErrorOut()
...
The downside to defer over RAII, of course, is that there's no static guarantee that you 1) remembered to include the defer, or 2) deferred the right thing. I could see that getting painful in some refactorings. Which isn't to say there aren't upsides.
Whenever you do forget, it's immediately obvious by looking at the function in question. Or by grepping things that "open" something to see if there's corresponding defer nearby.
In practise, it's not a big problem, because you learn fairly soon when doing something reversible that a defer is needed to reverse it when leaving scope/function. Like:
But I didn't need to write a ChdirToSomewhereAndBack wrapper class either. Control flow is completely obvious. All potential bugs are in plain sight, not hidden in some wrapper.
If you saw this code for the first time ever, you'd have absolutely no surprises or need to browse code in some class.
If you needed to do this chdir thing often, you could simply wrap it in a function:
In practise, it's not a big problem, because you learn fairly soon when doing something reversible that a defer is needed to reverse it when leaving scope/function. Like:
func DoSomethingInSomeDir() error
{
err := os.Chdir("somedir")
if err != nil { return err }
defer os.Chdir("..") // always done even if there's panic
... do the something that can fail
return nil
}
But I didn't need to write a ChdirToSomewhereAndBack wrapper class either. Control flow is completely obvious. All potential bugs are in plain sight, not hidden in some wrapper.
If you saw this code for the first time ever, you'd have absolutely no surprises or need to browse code in some class.
If you needed to do this chdir thing often, you could simply wrap it in a function:
func DoSomethingInANamedDir(dirName string, fn() error) error
{
err := os.Chdir(dirName)
if err != nil { return err }
defer os.Chdir("..") // always done even if there's panic
return fn(); // do the something that can fail
}
DoSomethingingInANamedDir("something",
func() err { ... something that can fail ... })
'Whenever you do forget, it's immediately obvious by looking at the function in question. Or by grepping things that "open" something to see if there's corresponding defer nearby.'
That's not great. Static guarantees are worlds better than "I can manually look at it, and manually grep for places I need to look".
"But I didn't need to write a ChdirToSomewhereAndBack wrapper class either."
That's not exactly hard, and if you're doing something frequently then writing something to abstract it away is the right approach. It's true that many languages leave defining that wrapper class ugly and push it far away from the site of use in one-offs.
"All potential bugs are in plain sight, not hidden in some wrapper."
That would be one of the upsides, yes. The related downsides are that there is more room for bugs because you have to get it right every time instead of just once, and bugs might be hidden in plain sight when there is too much clutter.
"If you needed to do this chdir thing often, you could simply wrap it in a function:"
That seems isomorphic to the RAII wrapper class, with slightly more syntactic cruft.
That's not great. Static guarantees are worlds better than "I can manually look at it, and manually grep for places I need to look".
"But I didn't need to write a ChdirToSomewhereAndBack wrapper class either."
That's not exactly hard, and if you're doing something frequently then writing something to abstract it away is the right approach. It's true that many languages leave defining that wrapper class ugly and push it far away from the site of use in one-offs.
"All potential bugs are in plain sight, not hidden in some wrapper."
That would be one of the upsides, yes. The related downsides are that there is more room for bugs because you have to get it right every time instead of just once, and bugs might be hidden in plain sight when there is too much clutter.
"If you needed to do this chdir thing often, you could simply wrap it in a function:"
That seems isomorphic to the RAII wrapper class, with slightly more syntactic cruft.
"That's not great. Static guarantees are worlds better than "I can manually look at it, and manually grep for places I need to look"."
Grepping or looking is pretty much what you need to do also in C++, if you happen to have the bug in the wrapper. There's no static guarantee that can figure out if there's no chdir back to original location.
Grepping or looking is pretty much what you need to do also in C++, if you happen to have the bug in the wrapper. There's no static guarantee that can figure out if there's no chdir back to original location.
If you have a bug in the wrapper, you fix it once in the wrapper, and it's more likely to have shown up in a test if that wrapper is used multiple places. There is no static guarantee that you wrote the wrapper right, but hopefully there is some guarantee that you used the wrapper right. Definitions can't outnumber uses (or errors in some of those definitions don't matter...).
[deleted]
I wasn't saying "Therefore, C++ is better than go", just that the code above was unnecessarily ugly. I actually think that exceptional conditions are usually better handled with return values, though ideally in a way that allows some constrained bubbling without too much boiler plate plumbing. Of languages I'm deeply familiar with, I think Haskell has the best facilities for this (mark it in the type system, hide it behind composition, require it's been handled in controlled places) but has facilities for crazy stuff too (some of which winds up unavoidable).
Haskell's type system does sound interesting. Been on my list to check out for a long time, but so little time.
I write C++ for living. About a year ago, I wrote one pet project in Go. 30k lines, complicated concurrency, two different TCP servers, thousands of simultaneous goroutines that send messages over channels to each other. I was shocked how good experience it has been from the start when it comes to error handling and general reliability. Despite being my first and only project in Go, the project just had pretty much no bugs.
We've used this project daily by handful of people for over half a year and so far just a few minor bugs have been reported.
I've never achieved that low initial defect count for similar size and complexity C++ projects.
I write C++ for living. About a year ago, I wrote one pet project in Go. 30k lines, complicated concurrency, two different TCP servers, thousands of simultaneous goroutines that send messages over channels to each other. I was shocked how good experience it has been from the start when it comes to error handling and general reliability. Despite being my first and only project in Go, the project just had pretty much no bugs.
We've used this project daily by handful of people for over half a year and so far just a few minor bugs have been reported.
I've never achieved that low initial defect count for similar size and complexity C++ projects.
Happy to hear about your good experience :)
RAII can get rid of that one try/finally, that's true. I was writing standard Java/C#/Python-eque code, however, which requires all those try/catches.
Here's what you get if you have some magic RAII file-closer object:
Here's what you get if you have some magic RAII file-closer object:
try {
f = os.Open(filename)
}
catch(Exception e) {
throw new Exception(string.Format("Failed to open config file: %s", e.Message))
}
try {
callFunctionThatMightErrorOut()
}
catch(Exception e) {
// handle error
}
> I was writing standard Java/C#/Python-eque code, however, which requires all those try/catches.
No, it doesn't; wrapping each function call that might throw an exception in its own try/catch is recognized as an antipattern in all of those languages.
Most likely, you'd want to do one try block, with possibly multiple catch blocks for more specific exceptions (but only if you can do something useful to handle those exceptions), although, really, if you are reading a configuration file and the function you are writing can't do anything meaningful with errors but rethrow them, you probably want something more like (and this would be a case for catching generic Exception):
No, it doesn't; wrapping each function call that might throw an exception in its own try/catch is recognized as an antipattern in all of those languages.
Most likely, you'd want to do one try block, with possibly multiple catch blocks for more specific exceptions (but only if you can do something useful to handle those exceptions), although, really, if you are reading a configuration file and the function you are writing can't do anything meaningful with errors but rethrow them, you probably want something more like (and this would be a case for catching generic Exception):
try {
f = os.Open(filename)
callFunctionThatMightErrorOut()
.
.
.
}
catch(Exception e) {
throw new FailedToReadConfigFileException(e)
}Except that the caller can't tell what failed - was it file.Open, or was it callFunctionThatMightErrorOut? They both just cause the same FailedToReadConfigFileException, so you've made it impossible for the caller to react differently to each failure. In addition, they may even throw the same type of error (FileNotFoundException, for example), which may make it hard even for a human looking at the error to understand what actually failed, without looking at the stack trace and going into the code (which should be a last resort).
> Except that the caller can't tell what failed - was it file.Open, or was it callFunctionThatMightErrorOut?
The caller knows that the function they called failed, and has as much detail from the underlying error as it makes sense to include in the special case Exception constructed from it.
> They both just cause the same FailedToReadConfigFileException
No, they cause the same class of exception. The data in that Exception can vary as much as necessary based on the data in the underlying exceptions thrown.
Yes, if you actually have a need to differentiate, you may need additional try/catches, but that's usually a violation of encapsulation that exposes internal implementation details of a method to calling code, which defeats much of the purpose of OO, or even merely structured, programming.
The caller knows that the function they called failed, and has as much detail from the underlying error as it makes sense to include in the special case Exception constructed from it.
> They both just cause the same FailedToReadConfigFileException
No, they cause the same class of exception. The data in that Exception can vary as much as necessary based on the data in the underlying exceptions thrown.
Yes, if you actually have a need to differentiate, you may need additional try/catches, but that's usually a violation of encapsulation that exposes internal implementation details of a method to calling code, which defeats much of the purpose of OO, or even merely structured, programming.
Sure, and of course RAII can be of benefit either way. I'm not a pro-exceptions partisan, just don't like extraneously ugly code in examples. :-P
The code will close the file in case of a panic?
And here's what it might have looked like if they had taken notes from a language with a good exception handling style:
using(File f = os.Open(filename)) {
callFunctionThatMightErrorOut()
}
This is really interesting to me because it shows what to think of the claim that explicit error handling makes go code more reliable than languages which use exceptions.
When using go I often get the feeling of doing something wrong. Because I know I'm supposed to "handle errors" but all I really want is the program to blow up and hand me a stack trace. This gives me the worst of both worlds, I have to manually trigger something that approaches the unhandled exception behavior of other languages while retaining the verbosity of explicit errors returns. Now it seems like I'm not the only person struggling with this.
Has anyone come up with a sane approach to that problem?
When using go I often get the feeling of doing something wrong. Because I know I'm supposed to "handle errors" but all I really want is the program to blow up and hand me a stack trace. This gives me the worst of both worlds, I have to manually trigger something that approaches the unhandled exception behavior of other languages while retaining the verbosity of explicit errors returns. Now it seems like I'm not the only person struggling with this.
Has anyone come up with a sane approach to that problem?
I wouldn't say "more reliable" -- I would say "easier to reason about". Errors are just another returned variable, nothing more, nothing less. Go doesn't encourage tracking two independent flow control sets -- one for exception flow, and one for normal program flow. I have seen all sorts of complex nastiness created via the multiple flow control sets in Java.
I write server code the runs for long periods of time, the amount of times I want to blow up and get a stack trace is exceptional low, only when continuing to run is more harmful than having the service completely down.
As for just wanting it to blow up -- just ignore the error handling, it will blow up. Instead of putting the error in a variable, just throw it away using _ ... and the next dependent thing will blow up. Not very elegant, but it will remove all the boilerplate you don't like, and it will crash hard like you do like... alternatively write a crashOnError(err error) function and call that passing in error -- and all it has to do is if (err != nil) { panic(err) }
I write server code the runs for long periods of time, the amount of times I want to blow up and get a stack trace is exceptional low, only when continuing to run is more harmful than having the service completely down.
As for just wanting it to blow up -- just ignore the error handling, it will blow up. Instead of putting the error in a variable, just throw it away using _ ... and the next dependent thing will blow up. Not very elegant, but it will remove all the boilerplate you don't like, and it will crash hard like you do like... alternatively write a crashOnError(err error) function and call that passing in error -- and all it has to do is if (err != nil) { panic(err) }
For tiny programs you use yourself "blowing up" is fine. For code in production, it's probably not. Thinking about what can go wrong and writing code to handle it ahead of time is a large part of software engineering. If the network times out trying to download that file, what do you do? Do you blow up? Or do you retry a few times first? Do you pass the error back and let the caller do the retry? This is the stuff Go makes you think about. This is what makes your programs more robust. Things break in the real world, good code handles that gracefully. Blowing up is not graceful.
> Because I know I'm supposed to "handle errors" but
> all I really want is the program to blow up and hand me
> a stack trace . . . Has anyone come up with a sane
> approach to that problem?
It's natural that most public code panics on error, even though it's bad practice.
Error return values (e.g. go) are better for building large systems where stability & predictability are important (that is, cost to maintain).
Exceptions are better for quickly building systems (that is, cost to build).
Error return values (e.g. go) are better for building large systems where stability & predictability are important (that is, cost to maintain).
Exceptions are better for quickly building systems (that is, cost to build).
You have that completely backwards.
Exceptions are much better for large systems. You can define standardised behaviour regardless of where an error occurs. You can let unexpected errors 'bubble up' and be managed in a way that preserves the integrity of the system. You have the flexibility to recover from errors and let errors be silenced.
There is unparalleled flexibility with exceptions. Go's approach is frankly arcane.
Exceptions are much better for large systems. You can define standardised behaviour regardless of where an error occurs. You can let unexpected errors 'bubble up' and be managed in a way that preserves the integrity of the system. You have the flexibility to recover from errors and let errors be silenced.
There is unparalleled flexibility with exceptions. Go's approach is frankly arcane.
You are 100% right on unparalleled flexibility. Why limit your self to one set of flow control operators when you can have two! Also, lets make one break out of another one at any point of exception! The flexibility is endless!
You are 100% right, it is terrifyingly flexible. There is a reason exceptions as flow control is considered an anti-pattern.
You are 100% right, it is terrifyingly flexible. There is a reason exceptions as flow control is considered an anti-pattern.
So what you're saying is that the fundamental core of Java, Scala, Clojure are anti-patterns ? That's a strong statement for a platform that almost every enterprise application uses.
Go's error handling approach is also flow control. You receive an error and have to go and do something different based on that error. With Go it is explicit. With say Java you have the choice of being explicit or implicit. Flexibility is vital when you are working on large applications where the business logic varies wildly throughout the system.
Go's error handling approach is also flow control. You receive an error and have to go and do something different based on that error. With Go it is explicit. With say Java you have the choice of being explicit or implicit. Flexibility is vital when you are working on large applications where the business logic varies wildly throughout the system.
Yes, we're saying the fundamental core of Java is an anti-pattern. Exceptions are dangerous. At any point in a function, you can suddenly jump out of that function due to an exception. It's certainly possible to write correct programs with exceptions, but it's quite hard, and almost no one does it correctly. If your code isn't chock full of try/finally blocks, then you're not doing it right.
Explicit is way better than implicit by an order of magnitude. It means you can look at any Go code and instantly understand what the control flow will be. You can't do that with languages that have exceptions.
Explicit is way better than implicit by an order of magnitude. It means you can look at any Go code and instantly understand what the control flow will be. You can't do that with languages that have exceptions.
Right - and we're saying that it's not. Exceptions handled incorrectly are not anymore dangerous than incorrectly handling an error in Golang. At least with exceptions, I can easily see the code that handles them in contrast to the code that doesn't.
>> At any point in a function, you can suddenly jump...
That's kind of the point. There's a separate path for exceptional behavior, which is what makes reasoning about exception paths easier.
>> It's certainly possible to write correct programs with exceptions, but it's quite hard, and almost no one does it correctly.
You keep saying that, but where's the proof that Golang programs are any more "correct"? How exactly are you quantifying that?
>> Explicit is way better than implicit by an order of magnitude.
That's like saying that having to think about putting one foot in front of the other is better than just walking down the street. It's rather ridiculous to say that.
>> It means you can look at any Go code and instantly understand what the control flow will be.
Not at all because your control of flow is now so concerned with error handling that you can't see the intended "happy path" logic.
>> At any point in a function, you can suddenly jump...
That's kind of the point. There's a separate path for exceptional behavior, which is what makes reasoning about exception paths easier.
>> It's certainly possible to write correct programs with exceptions, but it's quite hard, and almost no one does it correctly.
You keep saying that, but where's the proof that Golang programs are any more "correct"? How exactly are you quantifying that?
>> Explicit is way better than implicit by an order of magnitude.
That's like saying that having to think about putting one foot in front of the other is better than just walking down the street. It's rather ridiculous to say that.
>> It means you can look at any Go code and instantly understand what the control flow will be.
Not at all because your control of flow is now so concerned with error handling that you can't see the intended "happy path" logic.
The whole point is that exception handling code, when written robustly, looks almost like Go error handling code. That or you need to write a TON of magic cleanup classes which take a lot of time, are even more error prone, and less flexible than boring error handling code.
What most people do, is they would let this function throw FileNotFoundException, and not catch it. There's at least three problems with that:
1. It leaks your implementation, so if later you're saving to memcache, you'll throw some different error, which could break consumers that have written code to handle the FileNotFoundException
2. It lacks context: file not found: foo.yaml ... wtf is foo.yaml and why was this random function trying to open it?
3. You can't tell programmatically what failed. Something threw a filenotfound... but you don't know if it was opening the config file or some other function, so you can't handle it properly.
There's also the fact that now anyone who calls your function needs to wrap it in a try/catch, or let an exception from 2 levels deep bubble up. So you can get FileNotFound: foo.yaml from your Initiate() function, and no one knows what that means.
That's what I mean by "almost no one [handles exceptions] correctly".
f, err := os.Open(filename)
if err != nil {
return fmt.Errorf("failed to open config file: %s", err)
}
// happy path
File f;
try {
f = File.Open(filename)
}
catch (Exception e) {
throw new Exception(String.Format("failed to open config file: %s", e.Message))
}
// happy path
What most people do, is they would let this function throw FileNotFoundException, and not catch it. There's at least three problems with that:
1. It leaks your implementation, so if later you're saving to memcache, you'll throw some different error, which could break consumers that have written code to handle the FileNotFoundException
2. It lacks context: file not found: foo.yaml ... wtf is foo.yaml and why was this random function trying to open it?
3. You can't tell programmatically what failed. Something threw a filenotfound... but you don't know if it was opening the config file or some other function, so you can't handle it properly.
There's also the fact that now anyone who calls your function needs to wrap it in a try/catch, or let an exception from 2 levels deep bubble up. So you can get FileNotFound: foo.yaml from your Initiate() function, and no one knows what that means.
That's what I mean by "almost no one [handles exceptions] correctly".
>So what you're saying is that the fundamental core of Java, Scala, Clojure are anti-patterns ? That's a strong statement for a platform that almost every enterprise application uses.
Just so. You think something being used in enterprise is a worthy argument?
Just so. You think something being used in enterprise is a worthy argument?
It's sadly much too common to abuse exceptions for non-exceptional situations.
That doesn't mean Go's "error handling" is any better.
It's probably the worst approach one can pick. (But this has been discussed dozens of times already and Go fans have decided that they don't want to hear it.)
That doesn't mean Go's "error handling" is any better.
It's probably the worst approach one can pick. (But this has been discussed dozens of times already and Go fans have decided that they don't want to hear it.)
>It's probably the worst approach one can pick. (But this has been discussed dozens of times already and Go fans have decided that they don't want to hear it.)
Rust and Swift designers picked a similar approach. Is it possible that three separate designers of languages are so bound by language trends that they decided to make the almost exact same mistakes?
Rust and Swift designers picked a similar approach. Is it possible that three separate designers of languages are so bound by language trends that they decided to make the almost exact same mistakes?
No, they didn't. Go's approach is wrong, Rust's and Swift's are right.
Saying exceptions are for exceptional situations is an old fallacy (one I used to believe in). Exceptions are errors. Errors happen all the time. They are not exceptional.
Sure they are. Just because something happens all the time doesn't mean that it's not exceptional. Banks get robbed all the time, but that's still the exception to the rule that people usually go to the bank for normal business.
At the "Bank of Golang" though - they've made every customer get strip searched on their way in because of something that happens 1% of the time. No thanks. I'd rather go across the street where they simply have some cameras and security guards watching the crowd for exceptional behavior.
At the "Bank of Golang" though - they've made every customer get strip searched on their way in because of something that happens 1% of the time. No thanks. I'd rather go across the street where they simply have some cameras and security guards watching the crowd for exceptional behavior.
That's utter non-sense.
There is slight difference between "the database is on fire" and "a user with user id 42 couldn't be found in the database", don't you think?
Go handles neither of these situations gracefully.
There is slight difference between "the database is on fire" and "a user with user id 42 couldn't be found in the database", don't you think?
Go handles neither of these situations gracefully.
Let me guess, it logs something somewhere that no one ever checks? Or equally likely, you'll find this:
void SomeHighLevelMethod() {
...
catch (const DatabaseOnFireException& e) {
// TODO log something here
// TODO do something here
}
...
}I don't seem to understand what about returning error values stops any flexibility. I have built several things in Golang, and you absolutely have the ability to continue to return error values ("bubbling up") until a function has the ability to handle or silence it.
I get the personal preference one way or another, but can you go into more detail about what specific features one loses with Go's approach?
I get the personal preference one way or another, but can you go into more detail about what specific features one loses with Go's approach?
And, in fact, bubbling errors up is very common in my code:
func (t *Thing) Delete() error {
count, err := db.Delete(t)
if err != nil {
return err
}
if count != 1 {
return errors.New("delete Thing didn't delete 1 row? count: " + string(count))
}
return nil
}Indeed the majority of the time the correct way to handle an error is to propagate it up to the caller...no shit. which is why requiring manual plumbing everywhere to do just that is ridiculous. And forgetting this manual check even once is devastating.
And exceptions are not the only thing that do this automatically for you, so this is just flat out horrible design decision.
And exceptions are not the only thing that do this automatically for you, so this is just flat out horrible design decision.
> Exceptions are much better for large systems.
I deal with systems that contain millions* of lines of C++. Exceptions are killing us. How much larger do we need to get until I can expect to see the advantages?
* I haven't actually counted those lines or even wc -l'd them.
I deal with systems that contain millions* of lines of C++. Exceptions are killing us. How much larger do we need to get until I can expect to see the advantages?
* I haven't actually counted those lines or even wc -l'd them.
Those are claims that need some serious evidence to back them.
Maybe it would be better use the title of the submission to draw attention to exactly what is interesting here. All I can see is "lots of people use 'err' as the name of their returned error value in Go code on ohloh"
Most of the time, the only things done with an error are fatal exit or panic - the same code, over and over and over again.
It looks much worse than exceptions. (Except C++ and Java exceptions, as both are exception anti-patterns in different ways.)
It looks much worse than exceptions. (Except C++ and Java exceptions, as both are exception anti-patterns in different ways.)
I don't know what codebases this covers, but GOOD Go code does not panic.
GOOD <insert your language here> code does not panic. Except people write code...
But this seems more like "good Haskell code does not use unsafePerformIO" than "good C code does not segfault" - if you can find violations with a grep, it's much less of a concern to rely on programmers to get it right and not use it where inappropriate (which is not to say it's not a concern at all).
When something has an error, you have approximately four choices:
1) fix it locally 2) terminate 3) ignore 4) delegate decision to caller
(1) is rarely an option because failure conditions are usually beyond the control of the low-level code performing the operation. That's because error conditions usually occur at the edges of an application, typically I/O of some sort, and typically are the implementation of a higher-level semantic action. If you're trying to open a file or connect to an address, what can you reasonably do if the file is missing or the network is unavailable?
(2) is not an option for systems beyond a trivial size, unless the system is composed out of little executables. There's an argument for going this route in an actor system, but most Go apps are not actor systems.
(3) is usually only an option for throwaway programs - they're probably better off terminating, in case they do something bad after preconditions have been violated.
Which leaves (4) - delegation to the caller. This is the most composable option, since it lets the composer of the components control the error strategy. In its most flexible form, this looks something like Lisp conditions; it's easy enough to emulate with a stack of error handler callbacks, but the benefits only come when the handling system is consistently used everywhere. The more common version is to unwinds the stack until someone is able to deal with the problem.
Whether you unwind explicitly with checks to an 'err' return code, or implicitly with panic, or with longjmp, or with exceptions in a language with that feature, doesn't really matter. You're still doing the same thing, semantically and with code flow.
Which error handling strategy is more error prone?
The most manual one - the one that makes it easiest to drop the error on the floor, or otherwise molest it on its path from cause to handler - would be my bet.
Java's pathology here is statically checked exceptions; this encourages molestation of the error on its path, since the error value potentially needs to be of a different type at different points in the code flow. This risks obscuring the cause of the error, since errors are a function of implementation - but Java encourages expressing errors in terms of interface.
C++'s pathology is that it allows code flow through user provided code that is ill suited to throwing exceptions. The added complexity spawns whole books worth of material on how to write C++ code in an exception safe manner.
Good exception handling style in languages with sane exceptions normally means almost never catching exceptions except for high level orchestration routines; reacting to unwinding by cleaning up resources; and generally taking a transactional approach to operations.
I believe that good error handling with explicit error codes doesn't do anything semantically different in response to an error - it just does it all manually, i.e. in an error-prone fashion. And it's my biggest problem with Go.
1) fix it locally 2) terminate 3) ignore 4) delegate decision to caller
(1) is rarely an option because failure conditions are usually beyond the control of the low-level code performing the operation. That's because error conditions usually occur at the edges of an application, typically I/O of some sort, and typically are the implementation of a higher-level semantic action. If you're trying to open a file or connect to an address, what can you reasonably do if the file is missing or the network is unavailable?
(2) is not an option for systems beyond a trivial size, unless the system is composed out of little executables. There's an argument for going this route in an actor system, but most Go apps are not actor systems.
(3) is usually only an option for throwaway programs - they're probably better off terminating, in case they do something bad after preconditions have been violated.
Which leaves (4) - delegation to the caller. This is the most composable option, since it lets the composer of the components control the error strategy. In its most flexible form, this looks something like Lisp conditions; it's easy enough to emulate with a stack of error handler callbacks, but the benefits only come when the handling system is consistently used everywhere. The more common version is to unwinds the stack until someone is able to deal with the problem.
Whether you unwind explicitly with checks to an 'err' return code, or implicitly with panic, or with longjmp, or with exceptions in a language with that feature, doesn't really matter. You're still doing the same thing, semantically and with code flow.
Which error handling strategy is more error prone?
The most manual one - the one that makes it easiest to drop the error on the floor, or otherwise molest it on its path from cause to handler - would be my bet.
Java's pathology here is statically checked exceptions; this encourages molestation of the error on its path, since the error value potentially needs to be of a different type at different points in the code flow. This risks obscuring the cause of the error, since errors are a function of implementation - but Java encourages expressing errors in terms of interface.
C++'s pathology is that it allows code flow through user provided code that is ill suited to throwing exceptions. The added complexity spawns whole books worth of material on how to write C++ code in an exception safe manner.
Good exception handling style in languages with sane exceptions normally means almost never catching exceptions except for high level orchestration routines; reacting to unwinding by cleaning up resources; and generally taking a transactional approach to operations.
I believe that good error handling with explicit error codes doesn't do anything semantically different in response to an error - it just does it all manually, i.e. in an error-prone fashion. And it's my biggest problem with Go.
"Good exception handling style in languages with sane exceptions normally means almost never catching exceptions except for high level orchestration routines; reacting to unwinding by cleaning up resources; and generally taking a transactional approach to operations."
I agree. Except that is really really really hard. How does your orchestration routine know to close the file handle that was opened 6 levels deep in the code? How does it know to return 404 not found to the request that was being handled 4 levels deep? It can't, and if it does, then you're breaking encapsulation.
The reality of the situation is that the only place where you have the knowledge to clean up after a function is inside that function. I suppose in theory you could write a whole crapload more code to create auto-clean-up objects and transactional frameworks.... and that'll take a lot longer and be a lot buggier, and be a lot less flexible than just handling the error near to where it was produced with boring, straight-forward code, which is how it works in Go.
I agree. Except that is really really really hard. How does your orchestration routine know to close the file handle that was opened 6 levels deep in the code? How does it know to return 404 not found to the request that was being handled 4 levels deep? It can't, and if it does, then you're breaking encapsulation.
The reality of the situation is that the only place where you have the knowledge to clean up after a function is inside that function. I suppose in theory you could write a whole crapload more code to create auto-clean-up objects and transactional frameworks.... and that'll take a lot longer and be a lot buggier, and be a lot less flexible than just handling the error near to where it was produced with boring, straight-forward code, which is how it works in Go.
> Except that is really really really hard. How does your orchestration routine know to close the file handle that was opened 6 levels deep in the code?
It doesn't need to. Which is why "never catching exceptions except for high-level orchestration routines" is a separate point from "reacting to unwinding by cleaning up resources".
What is being said is that, in good exception handling style, Orchestration routines use try/except (they might use "finally" if they also have local resources to clean up), and lower-level routines use try/finally without "except".
> and that'll take a lot longer and be a lot buggier, and be a lot less flexible than just handling the error near to where it was produced with boring, straight-forward code, which is how it works in Go.
With Go, you pretty much do the same thing -- lower level code cleans up its own resources (with defer in place of finally) and will propagates errors up in the same circumstances that code would in other languages (with explicitly error returns rather than implicit propagation of exceptions), and higher level orchestration routines are mostly where you do something more with the error returns.
It doesn't need to. Which is why "never catching exceptions except for high-level orchestration routines" is a separate point from "reacting to unwinding by cleaning up resources".
What is being said is that, in good exception handling style, Orchestration routines use try/except (they might use "finally" if they also have local resources to clean up), and lower-level routines use try/finally without "except".
> and that'll take a lot longer and be a lot buggier, and be a lot less flexible than just handling the error near to where it was produced with boring, straight-forward code, which is how it works in Go.
With Go, you pretty much do the same thing -- lower level code cleans up its own resources (with defer in place of finally) and will propagates errors up in the same circumstances that code would in other languages (with explicitly error returns rather than implicit propagation of exceptions), and higher level orchestration routines are mostly where you do something more with the error returns.
OK, so I don't think we're disagreeing at all then, except possibly about the difficulty / commonality of writing the correct exception handling code.
I think its difficult to do right and frequently done wrong. I'm just not completely convinced that Go makes that significantly better (there is an advantage to being more explicit, but it comes at the cost of making what is usually right -- propagating errors back up the chain -- easy to omit, and lots of sample code silently swallows errors to avoid distraction, which has value for what it is trying to teach but might incidentally also breed bad habits.)
It probably makes the most common mistakes in error handling in Go different than with languages where the preferred method is more "traditional" exceptions, because the easiest mistakes to make are different.
It probably makes the most common mistakes in error handling in Go different than with languages where the preferred method is more "traditional" exceptions, because the easiest mistakes to make are different.
Cleanup can be done with techniques like try/finally, using-blocks, closure nesting like Ruby, RAII like C++, or defer like Go - all completely orthogonal to checking for errors and returning.
So I get it, and it makes a good point, but this could be more of a symptom than a disease.
When I first started programming C I also tended to just exit the program on getting a bad return code, because I'd never been taught how to properly handle errors - I'd always just replied on exceptions.
Only later did I start to get bitten, and take proper care to handle errors sensibly and explicitly.
As "go" is such a new language I wouldn't be surprised if a similar thing has happened to new programmers migrating over to it.
When I first started programming C I also tended to just exit the program on getting a bad return code, because I'd never been taught how to properly handle errors - I'd always just replied on exceptions.
Only later did I start to get bitten, and take proper care to handle errors sensibly and explicitly.
As "go" is such a new language I wouldn't be surprised if a similar thing has happened to new programmers migrating over to it.
I find that I wind up "bubbling up" errors of my own to build a stack trace yet still retain control of my program, like:
func LowLevelCode() (int, error) {
// rest of body...
if /* error condition */ {
return 0, errors.New("LowLevelCode error: " + /* error description */)
}
}
func MiddleWare() (interface{}, error) {
// body of code...
nCount, err := LowLevelCode()
if err != nil {
return nil, errors.New("MiddleWare error: " + err.Error())
}
}
func ApplicationCode() {
// Do cool stuff...
obj, err := MiddleWare()
if err != nil {
log.Println(err) // Prints "MiddleWare error: LowLevelCode error: " + ...
// Handle on a high level, retry connections, etc.
}
}
There are a lot of error handling libraries out there. On Juju, we're working on one right now. This is the preliminary version: https://github.com/juju/errgo
Basically you just call a function every time you would return an error, and it automatically records the file and line number and lets you add on some context to the message, plus it gives you the option to mask the type of the error (to hide implementation details from your callers).
I wouldn't use errgo right now, it's still under heavy development, but it's similar to a lot of other error handling libraries out there.
Basically you just call a function every time you would return an error, and it automatically records the file and line number and lets you add on some context to the message, plus it gives you the option to mask the type of the error (to hide implementation details from your callers).
I wouldn't use errgo right now, it's still under heavy development, but it's similar to a lot of other error handling libraries out there.
This is what I used.
http://golang.org/pkg/runtime/#Stack
http://golang.org/pkg/runtime/#Stack
I like erlang's model here. Fail often and fail fast and let the supervisor of that particular node just restart the thing. Bug fixing comes later when you inspect your logs. Do errors bubble up in actors in go like they do in erlang?
How is that different from exceptions, really? It's just less granular, but exactly what e.g. Django (a Python web framework) foes with exceptions (per-request, not per-process).
Is this meant to be a negative comment on Go error handling not conforming to a single pattern, or a positive comment on Go error handling not needing to conform to a single pattern?
Or is it just a random code search posted on HN?
Or is it just a random code search posted on HN?
I've found in some cases Go's style of error handling can actually make for great documentation: when every third line of code is something like
if err != nil{
log.Printf("This specific operation %v went
wrong because input %v was %v or was expected to be %v but
wasn't", operationName, inputName, actualInput,
expectedInput)
}
I don't see what's interesting with this?
I think it shows that while the Go people usually say that their error handling is better than exception, most often they either exit on exception (which is like not catching an exception) or pass the error up the call stack (the default behaviour for an uncaught exception). This means that this way of doing error handling is actually just verbose.
Which is also my opinion.
Which is also my opinion.
> most often they either exit on exception (which is like
> not catching an exception)
> or pass the error up the call stack (the default
> behaviour for an uncaught exception)
The "Eureka" of error handling in Go isn't a massive thing. It's just the reification of the small and important understanding that errors are values, just like anything else.
Well, Java tried to make it explicit with checked exceptions, and everyone hated that. And checked exception are a much better design than the way Go does it: either you catch, which is like checking the error value in Go, or you don't and annotate your function signature with "throws MyException", which is more explicit and terser.
The thing that some Go fans miss is that it's actually pretty rare (in my own experience, but I've seen a lot of people echo the same thing) to have to deal with an exception. Usually an exception means that the show is over -- at best you'll report it to the user and continue running your main loop if your application is interactive. Or you may retry the operation a certain number of times.
But most of the time you just want to stop the application, or let some upper level deal with it, and those are exactly the default behaviors of exceptions.
The thing that some Go fans miss is that it's actually pretty rare (in my own experience, but I've seen a lot of people echo the same thing) to have to deal with an exception. Usually an exception means that the show is over -- at best you'll report it to the user and continue running your main loop if your application is interactive. Or you may retry the operation a certain number of times.
But most of the time you just want to stop the application, or let some upper level deal with it, and those are exactly the default behaviors of exceptions.
So, your argument is that - because you actually see some code that simply propagates an error, it's easier to reason about where the error ends up being handled? That's like saying you'd rather search for a needle in a haystack than a needle on a platter.
With un-checked exception handling code, all I have to do is look for "catches" in the call stack to my function. That code stands out and it's easy to find. With Golang, I have to spend way more energy analyzing every caller in the stack because they all touch my error.
With un-checked exception handling code, all I have to do is look for "catches" in the call stack to my function. That code stands out and it's easy to find. With Golang, I have to spend way more energy analyzing every caller in the stack because they all touch my error.
> So, your argument is that - because you actually see
> some code that simply propagates an error, it's easier
> to reason about where the error ends up being handled?
> That's like saying you'd rather search for a needle in
> a haystack than a needle on a platter.
> With Golang, I have to spend way more energy analyzing
> every caller in the stack because they all touch my
> error.
Yeah, I don't get the point of this; that's how it's done in Go. You might want to search "catch (Exception e)" for other languages.
Except in Go you would be manually "rethrowing" exceptions whereas in other languages that is done automatically.
It's verbose and explicit but this is like using tests for your programs: boring and annoying short term but very useful medium and long term.
Verbose and explicit is what made java checked exceptions the sign of the demon for some programmers. The err pattern in GO might end up the same.
In the end I think the problem is that there are two separate classes of programs. The first is where crash on exception is tolerable and even a desired property (or blindly and optimistically continuing). The second is always deal with exceptions and any error no matter how rare and unlikely they are, and attempt to recover and deal with them properly. No one language and standard library can really please both sides.
In the end I think the problem is that there are two separate classes of programs. The first is where crash on exception is tolerable and even a desired property (or blindly and optimistically continuing). The second is always deal with exceptions and any error no matter how rare and unlikely they are, and attempt to recover and deal with them properly. No one language and standard library can really please both sides.
Yes, that can definitely be the case. It's just a hard problem in general. So far the explicitness of Go's error handling reminds me a little bit of checked exceptions in Java: I appreciate the idea but I'm not sure it's the best thing we could do.
One goal, while writing programs, is to construct programs that operate correctly (that is conform to the specifications that we have or imagine for the finished product). Complex control flows make reasoning about correctness difficult. Consider a simple loop:
Once we introduce exceptions, we can end up outside the loop without knowing anything about the state of x and y (unless we examine a lot more code, possibly code quite remote from this little loop we are working on).
go's requirement to laboriously check and handle every function return may make it easier to reason about x and y in our little example, but it comes at the cost of extra boilerplate error checking everywhere. This too hurts our ability to reason about the code we are writing by increasing verbosity, so I'm not sure that go's approach will work out much better than some form of exceptions mechanism.
However, I welcome this approach to language design, keeping the language as simple as possible, but no simpler. Even if go error handling turns out in practice to be roughly as good as C++'s approach, it will be a big win for go because go ends up smaller, simpler, and easier to learn and master. It's difficult to assemble a team of C++ programmers to work on complex systems because it is so hard to find more than a handful of real C++ experts at a time. I feel safer recommending the use of go to a typical programming team than C++.
while x != y
x = ...
y = ...
end while
-- (A)
while x != y
x = ...
if x == 0: break
y = ...
end while
-- (B)
Once we introduce exceptions, we can end up outside the loop without knowing anything about the state of x and y (unless we examine a lot more code, possibly code quite remote from this little loop we are working on).
go's requirement to laboriously check and handle every function return may make it easier to reason about x and y in our little example, but it comes at the cost of extra boilerplate error checking everywhere. This too hurts our ability to reason about the code we are writing by increasing verbosity, so I'm not sure that go's approach will work out much better than some form of exceptions mechanism.
However, I welcome this approach to language design, keeping the language as simple as possible, but no simpler. Even if go error handling turns out in practice to be roughly as good as C++'s approach, it will be a big win for go because go ends up smaller, simpler, and easier to learn and master. It's difficult to assemble a team of C++ programmers to work on complex systems because it is so hard to find more than a handful of real C++ experts at a time. I feel safer recommending the use of go to a typical programming team than C++.
I find that a mustBeNil function is useful:
func mustBeNil(err error) {
if err != nil {
panic(err)
// or log.Fatal(err)
}
}
func mustBeNil(err error, msg string) {
if err != nil {
log.Fatalf("%s: %s", err, msg)
}
}
Please, pull that `panic(err)` line. It is widely accepted that is bad practice, and something you should not do.
You panic when a program is expected to crash because of irrecoverable corruption. Only.
You panic when a program is expected to crash because of irrecoverable corruption. Only.
> You panic when a program is expected to crash because of
> irrecoverable corruption.
Don't panic in the middle of your code. You can occasionally use panic during init() when it indicates a programmer error. Otherwise, just return an error.
mustNotBe?
Note that the other two hip languages of the moment, Rust and Swift, also do not rely on exceptions for error management.
If any of these calls to panic() are inside libraries, by using that library, you will put yourself into a position where your application will exit without giving you any recourse to fix it.
I've seen too many C libraries doing this too - "mmh - I can't handle this right now - let me just call exit()" (last time this happened was inside a commerical library for reading excel files. If it was confronted with a file that was corrupt in some way, the library would call exit(), terminating my application server in the process. Thanks)
With exceptions, a library can just throw but I as a consumer of the library at least get a chance to handle the error somehow and who knows - I might be able to find some way to still proceed and not crash.
If I don't handle that exception, oh well, then I crash anyways, but that's not different from the library calling exit or panic.
With exceptions, I also never risk that I (or a library I use) forgets to check for an exit code and proceeds to corrupt data (or crash way later at a seemingly unrelated point).
When I fail to catch an exception, I my application dies.
When I fail to check an error code, my application might possibly corrupt data.
Just because implementing exceptions in compiled languages is difficult and messy (C++) and because exceptions are slow doesn't mean we shouldn't be using them. It means that we have to improve our language and OSes in order for them to work without hacks and quickly enough because, honestly, the value they provide to me is big enough to warrant a bit of research.