4 ms·

It's also trivial to "just ignore errors" in a language based on checked exceptions: try { ok = foo() } catch (Exception e) { // Do not

by ngrilly 11y ago

It's also trivial to "just ignore errors" in a language based on checked exceptions: try { ok = foo() } catch (Exception e) { // Do nothing } Checked exceptions don't save you from "this kind of sloppy programming".

Retra 11y ago
And it'll happen frequently, because if you're just trying to test out `ok = foo()` and you're not sure if it'll work, then you've got to write four lines of awful boilerplate and go read an API reference just to get it to compile. Checked exceptions are supposed to encourage correctness, but there's no fudge room for playing around, so they are very not fun. As an aside, I once tried using a crypto library to do something fairly simple (encrypt a file I'm writing to disk), and I had to handle a whole stack of exceptions that I had no clue how to handle. So what can you do? You should be able to write code that provides sensible default behavior, but checked exceptions make you work to just get that behavior, which is not how default behavior is supposed to work.
- incepted 11y ago
  If you don't know how to handle an exception, just add it to your `throws` clause and let a caller handle it. That's the whole point of exception: letting you choose who is the most appropriate to handle the error. Return value errors like Go implements forces everyone to care about all errors, at all times, even those they can't handle, which is why you see the pattern ok, err:= Foo() if err { every ten lines in Go sources.
  - Retra 11y ago
    You (the programmer) still have to handle it. If I (as a person) don't know how to handle the exception, passing it up the call stack doesn't solve the problem, it just moves it to somewhere else. The problem is that I don't know where it should be handled, because it was exposing cryptic and obscure exception types that probably make sense to someone who really understands cryptography. I don't, so I just can't use that library. If those were runtime exceptions, my program would just crash on error, which is the default I wanted. I didn't want to pollute my code with error handling stuff just to try out some simple functionality. If they were runtime exceptions, I could learn to use the code from the ground up, not by having to understand the whole thing at once.
    - incepted 11y ago
      > it just moves it to somewhere else. That's exactly the point: not everyone along the method stack is forced to deal with it, only the one caller that knows how to handle it. > The problem is that I don't know where it should be handled Then don't handle it at all and let it crash the program. But at least you didn't add boiler plate simply bubbling up an Err at every level of the stack frames. > If those were runtime exceptions, my program would just crash on error, which is the default I wanted Sometimes it is, sometimes it isn't. Some exceptions should crash your program (runtime exceptions), others should be handled (checked exceptions). Languages that take correctness seriously should offer you both options.
      - Retra 11y ago
        I'm not talking about handling the error, I'm talking about boilerplate. In order to get the program to even crash on error, I had to handle 4 different kinds of exceptions. I'm as much a fan of expciciteness as anyone, but there's a difference between explicit and verbose. And there's a lot to be said for constructs that don't force you to indent your code every time you call a function. My goal wasn't to write correct code, it was to test something out. To get comfortable with the library and the task. Checked exceptions get in the way of that. >Languages that take correctness seriously should offer you both options. Rust and Haskell take correctness seriously and offer neither. Checked exceptions make perfect sense in terms of ensuring correctness, but they are awful for usability and they are not the only way to achieve correctness. >Some exceptions should crash your program (runtime exceptions), others should be handled (checked exceptions). Shouldn't the user determine that, not the implementor? Why should any exceptions not be checked?
        incepted 11y ago
        > Why should any exceptions not be checked? Because there are exceptions you can't do anything about (e.g. OutOfMemoryException) and exceptions that you don't know what to do with (e.g. an NPE where you didn't expect it). NPE is the poster child for an unchecked exception: if you know your code is throwing an NPE here, just fix it instead of catching the NPE.
incepted 11y ago
But you have to write the `catch` (or a `throws`). That's the point. Now if you choose to handle this stupidly, that's entirely your fault, but at least the compiler did its jobs by forcing you to think about the error case. In Go, the compiler doesn't enforce anything.
- ngrilly 11y ago
  How many lines of Go have you written before writing this? In Go, as in Java with checked exceptions, the compiler forces the programmer to handle the error. Using _ in Go is not idiomatic. It's the exact equivalent of using a try/catch block with nothing in the catch block in Java.
  - Karunamon 11y ago
    Or not checking for the exception at all. Certain classes of errors can and should be allowed to pass up the call stack and cause your program to die (something strange that I wasn't expecting and don't know how to handle happened, and now I'm in a bad state - safer to exit)
  - pcwalton 11y ago
    If you call a function that returns nothing but an error, Go does not force you to acknowledge the error's existence and will silently allow you to drop it.

by ngrilly 11y ago

Retra 11y ago

And it'll happen frequently, because if you're just trying to test out `ok = foo()` and you're not sure if it'll work, then you've got to write four lines of awful boilerplate and go read an API reference just to get it to compile. Checked exceptions are supposed to encourage correctness, but there's no fudge room for playing around, so they are very not fun. As an aside, I once tried using a crypto library to do something fairly simple (encrypt a file I'm writing to disk), and I had to handle a whole stack of exceptions that I had no clue how to handle. So what can you do? You should be able to write code that provides sensible default behavior, but checked exceptions make you work to just get that behavior, which is not how default behavior is supposed to work.

incepted 11y ago
If you don't know how to handle an exception, just add it to your `throws` clause and let a caller handle it. That's the whole point of exception: letting you choose who is the most appropriate to handle the error. Return value errors like Go implements forces everyone to care about all errors, at all times, even those they can't handle, which is why you see the pattern ok, err:= Foo() if err { every ten lines in Go sources.
- Retra 11y ago
  You (the programmer) still have to handle it. If I (as a person) don't know how to handle the exception, passing it up the call stack doesn't solve the problem, it just moves it to somewhere else. The problem is that I don't know where it should be handled, because it was exposing cryptic and obscure exception types that probably make sense to someone who really understands cryptography. I don't, so I just can't use that library. If those were runtime exceptions, my program would just crash on error, which is the default I wanted. I didn't want to pollute my code with error handling stuff just to try out some simple functionality. If they were runtime exceptions, I could learn to use the code from the ground up, not by having to understand the whole thing at once.
  - incepted 11y ago
    > it just moves it to somewhere else. That's exactly the point: not everyone along the method stack is forced to deal with it, only the one caller that knows how to handle it. > The problem is that I don't know where it should be handled Then don't handle it at all and let it crash the program. But at least you didn't add boiler plate simply bubbling up an Err at every level of the stack frames. > If those were runtime exceptions, my program would just crash on error, which is the default I wanted Sometimes it is, sometimes it isn't. Some exceptions should crash your program (runtime exceptions), others should be handled (checked exceptions). Languages that take correctness seriously should offer you both options.
    - Retra 11y ago
      I'm not talking about handling the error, I'm talking about boilerplate. In order to get the program to even crash on error, I had to handle 4 different kinds of exceptions. I'm as much a fan of expciciteness as anyone, but there's a difference between explicit and verbose. And there's a lot to be said for constructs that don't force you to indent your code every time you call a function. My goal wasn't to write correct code, it was to test something out. To get comfortable with the library and the task. Checked exceptions get in the way of that. >Languages that take correctness seriously should offer you both options. Rust and Haskell take correctness seriously and offer neither. Checked exceptions make perfect sense in terms of ensuring correctness, but they are awful for usability and they are not the only way to achieve correctness. >Some exceptions should crash your program (runtime exceptions), others should be handled (checked exceptions). Shouldn't the user determine that, not the implementor? Why should any exceptions not be checked?
      - incepted 11y ago
        > Why should any exceptions not be checked? Because there are exceptions you can't do anything about (e.g. OutOfMemoryException) and exceptions that you don't know what to do with (e.g. an NPE where you didn't expect it). NPE is the poster child for an unchecked exception: if you know your code is throwing an NPE here, just fix it instead of catching the NPE.

incepted 11y ago

But you have to write the `catch` (or a `throws`). That's the point. Now if you choose to handle this stupidly, that's entirely your fault, but at least the compiler did its jobs by forcing you to think about the error case. In Go, the compiler doesn't enforce anything.

ngrilly 11y ago
How many lines of Go have you written before writing this? In Go, as in Java with checked exceptions, the compiler forces the programmer to handle the error. Using _ in Go is not idiomatic. It's the exact equivalent of using a try/catch block with nothing in the catch block in Java.
- Karunamon 11y ago
  Or not checking for the exception at all. Certain classes of errors can and should be allowed to pass up the call stack and cause your program to die (something strange that I wasn't expecting and don't know how to handle happened, and now I'm in a bad state - safer to exit)
- pcwalton 11y ago
  If you call a function that returns nothing but an error, Go does not force you to acknowledge the error's existence and will silently allow you to drop it.