4 ms·

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 st

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).

threeseed 12y ago
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.
- MetaCosm 12y ago
  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.
  - threeseed 12y ago
    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.
    - dscrd 12y ago
      >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?
      - frowaway001 12y ago
        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.)
        NateDad 12y ago
        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.
        WorldWideWayne 12y ago
        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.
        frowaway001 12y ago
        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.
- huntaub 12y ago
  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?
  - randallsquared 12y ago
    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 }
    - esailija 12y ago
      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.
- vardump 12y ago
  > 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.
lomnakkus 12y ago
Those are claims that need some serious evidence to back them.

threeseed 12y ago

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.

MetaCosm 12y ago
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.
- threeseed 12y ago
  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.
  - dscrd 12y ago
    >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?
    - frowaway001 12y ago
      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.)
      - NateDad 12y ago
        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.
        WorldWideWayne 12y ago
        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.
        frowaway001 12y ago
        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.
huntaub 12y ago
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?
- randallsquared 12y ago
  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 }
  - esailija 12y ago
    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.
vardump 12y ago
> 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.

lomnakkus 12y ago

Those are claims that need some serious evidence to back them.