3 ms·

Alternative is using result or either monad and have first-class support for nomadic operations in the language so you don't have to waste three lines on every

Alternative is using result or either monad and have first-class support for nomadic operations in the language so you don't have to waste three lines on every function call just to propagate the error up

TeMPOraL 3y ago
That's just a hard-core technique for sweeping noise under the rug. It helps with this and similar cross-cutting concerts, but at a huge cost elsewhere. We are unlikely to improve on this until we finally abandon the idea of working directly on a single, plaintext codebase.
- golergka 3y ago
  Can you please explain, how exactly is this sweeping noise under the rug? Type system still forces you to explicitly handle the error case, one way or another.
  - TeMPOraL 3y ago
    Monadic techniques let you hide most of the noise coming from passing around the Result type, especially in code that would only pass the error state through. You still need to handle the error case explicitly somewhere, but you avoid writing error checks and early returns everywhere else. I say it's sweeping under the rug, because you still can't exactly ignore the presence of error handling when not interested in it, and the extra complexity cost of monadic mechanisms themselves still pops up elsewhere to ruin your day.
groestl 3y ago
Or just, like, exceptions, still good enough. It's not rocket science, almost anything is better than Go's approach, and only C's is worse.
- golergka 3y ago
  That's exactly what sweeping under a rug is. When you use exceptions, you throw type safety out of the window and have an implicit spooky dependency at a distance between one place in the code that throws an exception and another that catches it.
  - groestl 3y ago
    There's nothing magic-like with exceptions, and no spooky distance. It's what it looks like when you _really_ assume everything can fail. Go admits that with panics.
    - golergka 3y ago
      Of course there is. If you throw a FileNotFoundError exception from function readFile(), you have to actually read documentation or it's source code to know that you have to catch this exception when you use it (in most languages except like early versions of Java). Type system doesn't check it for you. And if at some point readFile() also begins throwing InsufficientPermissionError exception, the type system, once again, doesn't tell you to fix the code that uses it. If that's not the spooky action at a distance between the place where exception is thrown and where it should be handled, I don't know what is.
      - groestl 3y ago
        Typically, that happens at the top layer. The API, the UI, etc. All layers in between don't care, and should not care, about this, other than correctly cleaning up. But it's not "distance". Also, it makes the correct thing easy ("catch Throwable").
      - amalcon 3y ago
        >except like early versions of Java And also more recent versions of Java, such as the current one: https://docs.oracle.com/javase/8/docs/api/java/lang/Exception.html https://docs.oracle.com/javase/8/docs/api/java/lang/Exceptio... >Checked exceptions need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary. This is like... the one thing that Java did absolutely right, but for some reason it's also the thing people hate most about it? I've never understood why.

TeMPOraL 3y ago

That's just a hard-core technique for sweeping noise under the rug. It helps with this and similar cross-cutting concerts, but at a huge cost elsewhere. We are unlikely to improve on this until we finally abandon the idea of working directly on a single, plaintext codebase.

golergka 3y ago
Can you please explain, how exactly is this sweeping noise under the rug? Type system still forces you to explicitly handle the error case, one way or another.
- TeMPOraL 3y ago
  Monadic techniques let you hide most of the noise coming from passing around the Result type, especially in code that would only pass the error state through. You still need to handle the error case explicitly somewhere, but you avoid writing error checks and early returns everywhere else. I say it's sweeping under the rug, because you still can't exactly ignore the presence of error handling when not interested in it, and the extra complexity cost of monadic mechanisms themselves still pops up elsewhere to ruin your day.

groestl 3y ago

Or just, like, exceptions, still good enough. It's not rocket science, almost anything is better than Go's approach, and only C's is worse.

golergka 3y ago
That's exactly what sweeping under a rug is. When you use exceptions, you throw type safety out of the window and have an implicit spooky dependency at a distance between one place in the code that throws an exception and another that catches it.
- groestl 3y ago
  There's nothing magic-like with exceptions, and no spooky distance. It's what it looks like when you _really_ assume everything can fail. Go admits that with panics.
  - golergka 3y ago
    Of course there is. If you throw a FileNotFoundError exception from function readFile(), you have to actually read documentation or it's source code to know that you have to catch this exception when you use it (in most languages except like early versions of Java). Type system doesn't check it for you. And if at some point readFile() also begins throwing InsufficientPermissionError exception, the type system, once again, doesn't tell you to fix the code that uses it. If that's not the spooky action at a distance between the place where exception is thrown and where it should be handled, I don't know what is.
    - groestl 3y ago
      Typically, that happens at the top layer. The API, the UI, etc. All layers in between don't care, and should not care, about this, other than correctly cleaning up. But it's not "distance". Also, it makes the correct thing easy ("catch Throwable").
    - amalcon 3y ago
      >except like early versions of Java And also more recent versions of Java, such as the current one: https://docs.oracle.com/javase/8/docs/api/java/lang/Exception.html https://docs.oracle.com/javase/8/docs/api/java/lang/Exceptio... >Checked exceptions need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary. This is like... the one thing that Java did absolutely right, but for some reason it's also the thing people hate most about it? I've never understood why.