4 ms·

In Go, b) is really common. Most of my code will annotate a lower error with the context of the operation that was happening. You’ll ideally see errors at the t

by ratorx 2y ago

In Go, b) is really common. Most of my code will annotate a lower error with the context of the operation that was happening. You’ll ideally see errors at the top level like: “failed to process item ‘foo’: unable to open user database at ‘/some/path’: file does not exist” as an example. Here, the lowest level IO error (which could be quite unhelpful, because at best it can tell you the name of the file, but not WHY it’s being opened) is wrapped with the exact type of the file being opened (a user database) and why the database is being opened (some part of processing ‘foo’, could even generate better error message here). Although this is a bit of work (but in the grand scheme of things, not that much), it generates much better debugging info than a stack trace in a lot of situations, especially for non-transient errors because you can annotate things with method arguments. I think the common complaint of ‘if err != nil { return err }’ is generally not the case because well-written Go will usually prepend context to why the operation was being performed.

codr7 2y ago
It's perfectly possible, and a lot less work, to wrap exceptions on their way up the call stack. The difference is you have to remember it at EVERY SINGLE freaking call site in Go.
CharlieDigital 2y ago
I don't see how this is different from exceptions though? Exceptions just make it optional if you want to handle it at that level (and you can).
throwaway2037 2y ago
> Most of my code will annotate a lower error with the context of the operation that was happening. This is easy to solve with chained exceptions to add context. > it generates much better debugging info than a stack trace in a lot of situations, especially for non-transient errors because you can annotate things with method arguments. You cannot add method args to an exception message? I am confused.
- ratorx 2y ago
  It is definitely possible with exceptions, but it is not the norm (you can do it yourself, but will a library also do it?) because the norm in Java is to silently pass up exceptions as that is the most ergonomic thing. And once you start doing it with exceptions, there’s not much difference in the code you end up writing between errors and exceptions. In practice, I’ve found that when I write Go, I end up annotating most error returns, so the benefit of exceptions for me would be minimal.
  - Capricorn2481 2y ago
    > And once you start doing it with exceptions, there’s not much difference in the code you end up writing between errors and exceptions The difference is where you want to catch the error, and not doing a bunch of "plumbing code" for intermediate callers that don't need to know about that error. > because the norm in Java is to silently pass up exceptions as that is the most ergonomic thing Adding args to an exception is completely localized. Adding additional args to an error in Go could mean changing dozens of files. Not to mention I can actually make my own exceptions for the problem. They are like enums with data.
    - ratorx 2y ago
      > difference is where you want to catch the error Catching is pretty similar no? In Java you match by type and in Go, you match by `errors.Is`? I guess the static checking in Java js better, but in terms of code written it is no different. > additional args to error in Go could mean changing dozens of files Just to be clear, here we are talking about a function that already returns an exception/error and adding args to it? That is also a local change in Go as well. The call site already handle the interface for error, not sure why changing a field or modifying the error message would make a difference. Arguably, this type of thing is harder in Java. Adding a new type of exception requires modifying all dependent callers to declare/handle the exception (unless they handle the generic Exception), whereas in Go it is a local only change (except if you need to actually handle the error).
      - 2y ago

by ratorx 2y ago

codr7 2y ago

It's perfectly possible, and a lot less work, to wrap exceptions on their way up the call stack. The difference is you have to remember it at EVERY SINGLE freaking call site in Go.

CharlieDigital 2y ago

I don't see how this is different from exceptions though? Exceptions just make it optional if you want to handle it at that level (and you can).

throwaway2037 2y ago

> Most of my code will annotate a lower error with the context of the operation that was happening. This is easy to solve with chained exceptions to add context. > it generates much better debugging info than a stack trace in a lot of situations, especially for non-transient errors because you can annotate things with method arguments. You cannot add method args to an exception message? I am confused.

ratorx 2y ago
It is definitely possible with exceptions, but it is not the norm (you can do it yourself, but will a library also do it?) because the norm in Java is to silently pass up exceptions as that is the most ergonomic thing. And once you start doing it with exceptions, there’s not much difference in the code you end up writing between errors and exceptions. In practice, I’ve found that when I write Go, I end up annotating most error returns, so the benefit of exceptions for me would be minimal.
- Capricorn2481 2y ago
  > And once you start doing it with exceptions, there’s not much difference in the code you end up writing between errors and exceptions The difference is where you want to catch the error, and not doing a bunch of "plumbing code" for intermediate callers that don't need to know about that error. > because the norm in Java is to silently pass up exceptions as that is the most ergonomic thing Adding args to an exception is completely localized. Adding additional args to an error in Go could mean changing dozens of files. Not to mention I can actually make my own exceptions for the problem. They are like enums with data.
  - ratorx 2y ago
    > difference is where you want to catch the error Catching is pretty similar no? In Java you match by type and in Go, you match by `errors.Is`? I guess the static checking in Java js better, but in terms of code written it is no different. > additional args to error in Go could mean changing dozens of files Just to be clear, here we are talking about a function that already returns an exception/error and adding args to it? That is also a local change in Go as well. The call site already handle the interface for error, not sure why changing a field or modifying the error message would make a difference. Arguably, this type of thing is harder in Java. Adding a new type of exception requires modifying all dependent callers to declare/handle the exception (unless they handle the generic Exception), whereas in Go it is a local only change (except if you need to actually handle the error).
    - 2y ago