5 ms·

I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. There's a whole lot of space between "

by dilap 10y ago

I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. There's a whole lot of space between "include useful context in errors" and "exceptions". (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.)

throwaw199ay 10y ago
> I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. As opposed to panics? Checked exceptions don't blow up in your face, you have to handle them. Nil errors and type errors might yet these also happen to Go. I see no difference with Java here. Go isn't better when it comes to error handling, in fact Go is extremely tedious when it comes to error handling. > (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.) So Go has both(unchecked exceptions and errors as "value"), how does it make things better? it doesn't. If it did, the blog wouldn't be talking about people "handling errors the wrong way".
- dilap 10y ago
  I've found it helpful to distinguish between errors that are program bugs and errors that are conditions of the outside world (network errors, invalid data, etc). I think it depends somewhat on the kind of software you're writing. Being very careful with errors is quite handy for a long-running server processes; maybe (maybe!) not so worth it for a program that starts and stops within the attention span of a single user.
  - pvg 10y ago
    errors that are program bugs and errors that are conditions of the outside world That also happens to be the intended distinction between Java's checked and unchecked exceptions.
- hnbro 10y ago
  > you have to handle them the definition of "handle" widely varies, to the point of making the exercise near meaningless.
stouset 10y ago
> I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. You mean outside of accidentally running into a nil, and having your program spontaneously abort? Even worse, reliably testing for nil (`if (foo == nil)`) doesn't even save you because go's nils are typed. So `foo == nil` can actually return false even when foo is nil. Utter madness.
- Vendan 10y ago
  Go's nils aren't typed, it's just that an interface value can have a type and point at nil. Also, I've never run into this "problem" in all my time of using Go...
  - deleted 10y ago
    [deleted]
- dilap 10y ago
  Running into a nil would be an "unexpected condition". In that case, an exception (panic, in Go lingo) is reasonable. It is true that Go doesn't do as much as other languages to avoid nils. It's a small, unambitious language in some ways. (Like, it adds more typing than Python, not as much as rust or swift.) foo == nil will always tell you the truth. The edge case that trips people up at first that I think you're thinking of is that storing a nil-pointer into an interface will not give you a nil interface: package main import "fmt" type Foo struct{} func (f *Foo) Do() { fmt.Println("do the foo", f) } type Doer interface { Do() } func main() { var foo *Foo = nil fmt.Println(foo == nil) // true var doer Doer = foo fmt.Println(doer == nil) // false, because doer is (nil,Foo) doer.Do() // prints "do the foo <nil>" } https://play.golang.org/p/Ul9cX34qfF https://play.golang.org/p/Ul9cX34qfF That's because an interface is a (pointer,type) pair, so even if the pointer is nil, the type being non-nil will make the pair non-nil.
  - stouset 10y ago
    I understand how and why this works. But the fact that you can write some form of var foo *Foo = nil var bar Bar = foo foo == nil # true bar == nil # false is, to be completely honest, completely ridiculous. It means you can perform a sanity check for nil values and still accidentally operate on a nil value. Null references have been referred to by Tony Hoare as his billion-dollar mistake. We should not be reintroducing mistakes of this level of magnitude, and worse, compounding on them, in new languages invented with fifty years of hindsight.

by dilap 10y ago

throwaw199ay 10y ago

> I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. As opposed to panics? Checked exceptions don't blow up in your face, you have to handle them. Nil errors and type errors might yet these also happen to Go. I see no difference with Java here. Go isn't better when it comes to error handling, in fact Go is extremely tedious when it comes to error handling. > (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.) So Go has both(unchecked exceptions and errors as "value"), how does it make things better? it doesn't. If it did, the blog wouldn't be talking about people "handling errors the wrong way".

dilap 10y ago
I've found it helpful to distinguish between errors that are program bugs and errors that are conditions of the outside world (network errors, invalid data, etc). I think it depends somewhat on the kind of software you're writing. Being very careful with errors is quite handy for a long-running server processes; maybe (maybe!) not so worth it for a program that starts and stops within the attention span of a single user.
- pvg 10y ago
  errors that are program bugs and errors that are conditions of the outside world That also happens to be the intended distinction between Java's checked and unchecked exceptions.
hnbro 10y ago
> you have to handle them the definition of "handle" widely varies, to the point of making the exercise near meaningless.

stouset 10y ago

> I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. You mean outside of accidentally running into a nil, and having your program spontaneously abort? Even worse, reliably testing for nil (`if (foo == nil)`) doesn't even save you because go's nils are typed. So `foo == nil` can actually return false even when foo is nil. Utter madness.

Vendan 10y ago
Go's nils aren't typed, it's just that an interface value can have a type and point at nil. Also, I've never run into this "problem" in all my time of using Go...
- deleted 10y ago
  [deleted]
dilap 10y ago
Running into a nil would be an "unexpected condition". In that case, an exception (panic, in Go lingo) is reasonable. It is true that Go doesn't do as much as other languages to avoid nils. It's a small, unambitious language in some ways. (Like, it adds more typing than Python, not as much as rust or swift.) foo == nil will always tell you the truth. The edge case that trips people up at first that I think you're thinking of is that storing a nil-pointer into an interface will not give you a nil interface: package main import "fmt" type Foo struct{} func (f *Foo) Do() { fmt.Println("do the foo", f) } type Doer interface { Do() } func main() { var foo *Foo = nil fmt.Println(foo == nil) // true var doer Doer = foo fmt.Println(doer == nil) // false, because doer is (nil,Foo) doer.Do() // prints "do the foo <nil>" } https://play.golang.org/p/Ul9cX34qfF https://play.golang.org/p/Ul9cX34qfF That's because an interface is a (pointer,type) pair, so even if the pointer is nil, the type being non-nil will make the pair non-nil.
- stouset 10y ago
  I understand how and why this works. But the fact that you can write some form of var foo *Foo = nil var bar Bar = foo foo == nil # true bar == nil # false is, to be completely honest, completely ridiculous. It means you can perform a sanity check for nil values and still accidentally operate on a nil value. Null references have been referred to by Tony Hoare as his billion-dollar mistake. We should not be reintroducing mistakes of this level of magnitude, and worse, compounding on them, in new languages invented with fifty years of hindsight.