4 ms·

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handli

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.) The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ is more concerned about people labelling non-exception things as exceptions (so what?) or that try/except/finally is ugly. I agree with the latter, but even worse is littering code with if statements doing the manual equivalent of try/except/finally.

luriel 14y ago
After using Go for a while (and Python and Java and many other languages with exceptions for years), lack of exceptions is one of my favorite things about Go. Handling errors is not something magical that you have to worry might happen when and where you least expect it. Exceptions are specially bad in Python, because often they are not even documented as part of the API, so you are never sure when you call a library what it might or might not throw and when. And that is without going into how they are abused for convoluted control flow.
- rogerbinns 14y ago
  I agree that exceptions done badly are poor. That is especially the case with C++ where they were introduced later, and they are one of the things some people omit when picking the subset of C++ they use. I also don't think exceptions should be done without GC. Java's checked exceptions are very annoying. My experience in Python is the opposite than yours, but then I've only been using it for 12 years :-) Undocumented serious exceptions are no different than Go's panic - they will probably terminate the program. But the usual case is extremely useful and not littering intermediate functions with error handling is wonderful. And sure they can be abused, but virtually any functionality gives you "power" and that power can be used wrong. That isn't a good reason to take something away from the developers who would use them right.
  - luriel 14y ago
    > Undocumented serious exceptions are no different than Go's panic They are very different, in Go you only panic() for programmer errors: panic() is never part of any API, when you access any API you never have to worry about whatever it will panic() or not. Meanwhile in Python any function or method might throw an exception for almost any reason imaginable, but of course most people pretend they don't, because exception handling code would swamp your code. I have done plenty of Python programming, failure to properly handle exceptions is very common. > And sure they can be abused, but virtually any functionality gives you "power" and that power can be used wrong. Exceptions are particularly problematic because they are a hidden part of APIs, and you have to be aware of and deal with this hidden part libraries all the time, not just in code you write.
enneff 14y ago
The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief. In short, we didn't include exceptions because we don't need them. Why add all that complexity for such contentious gains?
- luriel 14y ago
  > In short, we didn't include exceptions because we don't need them. I would say that not only I don't need exceptions, I absolutely don't want them. A really annoying thing about languages with exceptions is how they contaminate code, exceptions are (often hidden and badly documented) part of the interface of libraries and packages which you have to deal with when you least expect it.
- jbellis 14y ago
  I'm with the grandparent. Every language that I've used that was created after C has included exceptions, and never once have I missed checking errno. I can understand why, coming from a C++ context, you'd want to avoid them like the plague, but other languages (Python, Java, Smalltalk, ...) do a good job of making them a first-class citizen in the language, which saves a LOT of boilerplate typing. Seeing call stacks implementing a half-assed exception catching mechanism makes me sad. (Okay, Java only gets half credit here, since its checked exceptions inflict a different kind of boilerplate, but my larger point remains.) Lack of exceptions is half the reason I'm not interested in writing Go code yet. The other half is that anything that seriously intends to replace C++ does need an escape hatch to allow manual memory management for when the GC's one-size-fits-all approach is simply a poor fit. For a language whose goal was explicitly to replace C++, this is an odd place to be tone deaf. I'm disappointed to see an attitude of "haha stupid C++ programmers don't understand that programmer efficiency is more important than CPU efficiency," instead of realizing that there are valid use cases where you do need to care about this and addressing them. Which is unfortunate.
  - 14y ago
ww520 14y ago
One school of thoughts is that exception is a non-local goto that might span many levels of calls, and that can be non-trivial to understand. Languages without exception has clear paths of return in a function.
- rogerbinns 14y ago
  True, but so what. The code I like the best is the code I don't even have to write. Having to write all the intermediary code between where an exception happens and where I'd like to handle it is annoying. And the "understanding" argument applies to other things, such as using a compiled language instead of assembly or GC instead of manual memory allocation.
  - enneff 14y ago
    That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug.
    - eta_carinae 14y ago
      > I don't mind writing code. You should mind writing code that the compiler can write for you, which is exactly what you do when you don't have exceptions (you simulate bubbling up the error manually).
    - batista 14y ago
      >That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug. The code you don't have to write, you also don't have to debug. So you SHOULD mind writing code.
      - nightski 14y ago
        The assumption here being that if you do not have exceptions, one must write all the intermediate code. That exceptions are the only way of avoiding this. While in Go this may be the case, it is not true in general. One could use an error monad to achieve the exact same thing, albeit in a much safer manner.

luriel 14y ago

After using Go for a while (and Python and Java and many other languages with exceptions for years), lack of exceptions is one of my favorite things about Go. Handling errors is not something magical that you have to worry might happen when and where you least expect it. Exceptions are specially bad in Python, because often they are not even documented as part of the API, so you are never sure when you call a library what it might or might not throw and when. And that is without going into how they are abused for convoluted control flow.

rogerbinns 14y ago
I agree that exceptions done badly are poor. That is especially the case with C++ where they were introduced later, and they are one of the things some people omit when picking the subset of C++ they use. I also don't think exceptions should be done without GC. Java's checked exceptions are very annoying. My experience in Python is the opposite than yours, but then I've only been using it for 12 years :-) Undocumented serious exceptions are no different than Go's panic - they will probably terminate the program. But the usual case is extremely useful and not littering intermediate functions with error handling is wonderful. And sure they can be abused, but virtually any functionality gives you "power" and that power can be used wrong. That isn't a good reason to take something away from the developers who would use them right.
- luriel 14y ago
  > Undocumented serious exceptions are no different than Go's panic They are very different, in Go you only panic() for programmer errors: panic() is never part of any API, when you access any API you never have to worry about whatever it will panic() or not. Meanwhile in Python any function or method might throw an exception for almost any reason imaginable, but of course most people pretend they don't, because exception handling code would swamp your code. I have done plenty of Python programming, failure to properly handle exceptions is very common. > And sure they can be abused, but virtually any functionality gives you "power" and that power can be used wrong. Exceptions are particularly problematic because they are a hidden part of APIs, and you have to be aware of and deal with this hidden part libraries all the time, not just in code you write.

enneff 14y ago

The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief. In short, we didn't include exceptions because we don't need them. Why add all that complexity for such contentious gains?

luriel 14y ago
> In short, we didn't include exceptions because we don't need them. I would say that not only I don't need exceptions, I absolutely don't want them. A really annoying thing about languages with exceptions is how they contaminate code, exceptions are (often hidden and badly documented) part of the interface of libraries and packages which you have to deal with when you least expect it.
jbellis 14y ago
I'm with the grandparent. Every language that I've used that was created after C has included exceptions, and never once have I missed checking errno. I can understand why, coming from a C++ context, you'd want to avoid them like the plague, but other languages (Python, Java, Smalltalk, ...) do a good job of making them a first-class citizen in the language, which saves a LOT of boilerplate typing. Seeing call stacks implementing a half-assed exception catching mechanism makes me sad. (Okay, Java only gets half credit here, since its checked exceptions inflict a different kind of boilerplate, but my larger point remains.) Lack of exceptions is half the reason I'm not interested in writing Go code yet. The other half is that anything that seriously intends to replace C++ does need an escape hatch to allow manual memory management for when the GC's one-size-fits-all approach is simply a poor fit. For a language whose goal was explicitly to replace C++, this is an odd place to be tone deaf. I'm disappointed to see an attitude of "haha stupid C++ programmers don't understand that programmer efficiency is more important than CPU efficiency," instead of realizing that there are valid use cases where you do need to care about this and addressing them. Which is unfortunate.
- 14y ago

ww520 14y ago

One school of thoughts is that exception is a non-local goto that might span many levels of calls, and that can be non-trivial to understand. Languages without exception has clear paths of return in a function.

rogerbinns 14y ago
True, but so what. The code I like the best is the code I don't even have to write. Having to write all the intermediary code between where an exception happens and where I'd like to handle it is annoying. And the "understanding" argument applies to other things, such as using a compiled language instead of assembly or GC instead of manual memory allocation.
- enneff 14y ago
  That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug.
  - eta_carinae 14y ago
    > I don't mind writing code. You should mind writing code that the compiler can write for you, which is exactly what you do when you don't have exceptions (you simulate bubbling up the error manually).
  - batista 14y ago
    >That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug. The code you don't have to write, you also don't have to debug. So you SHOULD mind writing code.
    - nightski 14y ago
      The assumption here being that if you do not have exceptions, one must write all the intermediate code. That exceptions are the only way of avoiding this. While in Go this may be the case, it is not true in general. One could use an error monad to achieve the exact same thing, albeit in a much safer manner.