3 ms·

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 fun

by NateDad 12y ago

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.

WorldWideWayne 12y ago
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.
- NateDad 12y ago
  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. f, err := os.Open(filename) if err != nil { return fmt.Errorf("failed to open config file: %s", err) } // happy path compare to: 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 So, either you write code that looks like this, which is just like the Go code, or you don't, and you're handling your errors in a poor fashion. 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".

by NateDad 12y ago

WorldWideWayne 12y ago

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.

NateDad 12y ago
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. f, err := os.Open(filename) if err != nil { return fmt.Errorf("failed to open config file: %s", err) } // happy path compare to: 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 So, either you write code that looks like this, which is just like the Go code, or you don't, and you're handling your errors in a poor fashion. 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".