3 ms·

In Java, I'd have to write 3 catch blocks. It's possible to write a blanket catch, toss it up to higher levels and make it someone else's problem. I vaguely r

by libria 12y ago

In Java, I'd have to write 3 catch blocks. It's possible to write a blanket catch, toss it up to higher levels and make it someone else's problem. I vaguely recall this being against Pike's vision of what "exceptional" means and he wanted a language that forces developers to think of disk/network failure as a very common case.

lclarkmichalek 12y ago
Given that every single error check there is just passing up the error, is it really that different from having exceptions that propagate along with RAII style resource cleanup? The vast vast vast majority of Go code simply propagates errors.
- sagichmal 12y ago
  > Given that every single error check there is just > passing up the error, is it really that different from > having exceptions that propagate along with RAII style > resource cleanup? Yes, it's fundamentally different. The whole point is to make those error blocks visible, so future maintainers are forced to deal with the reality that those invocations are fallible. Maybe there's a way to make the error handling less verbose, but hiding it altogether would subvert that explicit language design goal.
  - lclarkmichalek 12y ago
    Except, you know, just mindlessly typing out "if err != nil { return }" does not somehow force enlightenment upon the user. The error blocks are so uniform in their banality that future maintainers treat them the same way that error handling is treated in every other language.
    - invisible 12y ago
      The fundamental difference is that each separate error is accounted for rather than 4 lines all being treated as error points so you never know which could throw.
justinsb 12y ago
If you use try-with-resources in Java 7, you don't need to write any exception handling. The function would be '... throws IOException'. That seems to satisfy the "think of disk/network failure as a very common case" design goal with minimal boilerplate. That brings up a separate discussion on checked vs unchecked exceptions, but I guess we can save that one for comparisons against a language with unchecked exceptions!

by libria 12y ago

lclarkmichalek 12y ago

Given that every single error check there is just passing up the error, is it really that different from having exceptions that propagate along with RAII style resource cleanup? The vast vast vast majority of Go code simply propagates errors.

sagichmal 12y ago
> Given that every single error check there is just > passing up the error, is it really that different from > having exceptions that propagate along with RAII style > resource cleanup? Yes, it's fundamentally different. The whole point is to make those error blocks visible, so future maintainers are forced to deal with the reality that those invocations are fallible. Maybe there's a way to make the error handling less verbose, but hiding it altogether would subvert that explicit language design goal.
- lclarkmichalek 12y ago
  Except, you know, just mindlessly typing out "if err != nil { return }" does not somehow force enlightenment upon the user. The error blocks are so uniform in their banality that future maintainers treat them the same way that error handling is treated in every other language.
  - invisible 12y ago
    The fundamental difference is that each separate error is accounted for rather than 4 lines all being treated as error points so you never know which could throw.

justinsb 12y ago

If you use try-with-resources in Java 7, you don't need to write any exception handling. The function would be '... throws IOException'. That seems to satisfy the "think of disk/network failure as a very common case" design goal with minimal boilerplate. That brings up a separate discussion on checked vs unchecked exceptions, but I guess we can save that one for comparisons against a language with unchecked exceptions!