4 ms·

After coding some Java I understand why people hate exceptions. Suddenly the Golang authors ranting about exceptions seems somewhat rational. I mean they still

After coding some Java I understand why people hate exceptions. Suddenly the Golang authors ranting about exceptions seems somewhat rational. I mean they still added exceptions to Golang, but are so ashamed of it they named them something else. These people should have to code C++ for a while before being allowed to rant about exceptions. (real C++, not Google C++ which bans exceptions for historical reasons) But yeah, what the fuck are you doing, Java? I've yet to see a stack trace that was actually helpful.

the_af 6y ago
I've worked with Java for more than a decade and I've seen plenty of stack traces that were helpful. Stack traces aren't the problem; the problem is that programmers silently swallow exceptions without either handling them or passing them up. > Suddenly the Golang authors ranting about exceptions seems somewhat rational. Error handling in Golang is nothing to write home about, either.
- girvo 6y ago
  Frankly the only error handling that I haven’t actively disliked is in ML-derived languages with Either<L, R>, or Nim’s (and the latter really isn’t that far off from what we’re complaining about, but the community seems better at using it without the nested exception hell that Java and in my experience PHP can end up in)
  - the_af 6y ago
    Oh, I also like Either from Haskell. But it can get out of hand if misused by devs. Note I say "misused" -- but it happens. After all, if Java exceptions weren't misused, there wouldn't be any problem either.
- xorcist 6y ago
  Isn't swallowing (and passing) exceptions pretty much what they are for? Should you instead handle every error close to their source, exceptions would be an overly verbose way of doing it. But maybe it's just my specific kind of programming prejudice shining through here.
  - the_af 6y ago
    > Isn't swallowing (and passing) exceptions pretty much what they are for? No. You either pass them up or handle them. Silently swallowing them is a recipe for disaster, because nobody gets any info about what went wrong. In very limited cases -- e.g. "I don't care about this harmless error" -- it's correct to swallow them up, but Java devs tend to overuse it and disaster ensues. > Should you instead handle every error close to their source [...] You shouldn't. Handle those errors that it makes sense to handle, pass them up otherwise. Just don't swallow them.
  - knorker 6y ago
    > Should you instead handle every error close to their source I find that this is very rarely the case. Micro-operations failing means that a MUCH higher level operation has failed. If there's an error writing to the output file descriptor from deep within the decompression library, do you know what failed? The HTTP request. What can the decompression library, the IDS inspector, the logging system, the tracing system, or anything else do? They can just pass along the error. Hence so much "if err != nil { return err}" in Go. The vast VAST majority of errors are not handled, they are reported. Verbose? benchmark b("blah"); write(http_compress(logsize(backend_decompress(out_fd, in_fd))) It's extremely rare that something can recover from an error. And the things that can be recovered from are not exceptions in C++ (though they seem to be in Java, brrr).
apta 6y ago
Having worked on large golang code bases, I'd take Java exceptions anytime. golang error handling is not only atrocious (you end up having to manually re-invent exceptions anyway), but also error prone and dangerous.

the_af 6y ago

I've worked with Java for more than a decade and I've seen plenty of stack traces that were helpful. Stack traces aren't the problem; the problem is that programmers silently swallow exceptions without either handling them or passing them up. > Suddenly the Golang authors ranting about exceptions seems somewhat rational. Error handling in Golang is nothing to write home about, either.

girvo 6y ago
Frankly the only error handling that I haven’t actively disliked is in ML-derived languages with Either<L, R>, or Nim’s (and the latter really isn’t that far off from what we’re complaining about, but the community seems better at using it without the nested exception hell that Java and in my experience PHP can end up in)
- the_af 6y ago
  Oh, I also like Either from Haskell. But it can get out of hand if misused by devs. Note I say "misused" -- but it happens. After all, if Java exceptions weren't misused, there wouldn't be any problem either.
xorcist 6y ago
Isn't swallowing (and passing) exceptions pretty much what they are for? Should you instead handle every error close to their source, exceptions would be an overly verbose way of doing it. But maybe it's just my specific kind of programming prejudice shining through here.
- the_af 6y ago
  > Isn't swallowing (and passing) exceptions pretty much what they are for? No. You either pass them up or handle them. Silently swallowing them is a recipe for disaster, because nobody gets any info about what went wrong. In very limited cases -- e.g. "I don't care about this harmless error" -- it's correct to swallow them up, but Java devs tend to overuse it and disaster ensues. > Should you instead handle every error close to their source [...] You shouldn't. Handle those errors that it makes sense to handle, pass them up otherwise. Just don't swallow them.
- knorker 6y ago
  > Should you instead handle every error close to their source I find that this is very rarely the case. Micro-operations failing means that a MUCH higher level operation has failed. If there's an error writing to the output file descriptor from deep within the decompression library, do you know what failed? The HTTP request. What can the decompression library, the IDS inspector, the logging system, the tracing system, or anything else do? They can just pass along the error. Hence so much "if err != nil { return err}" in Go. The vast VAST majority of errors are not handled, they are reported. Verbose? benchmark b("blah"); write(http_compress(logsize(backend_decompress(out_fd, in_fd))) It's extremely rare that something can recover from an error. And the things that can be recovered from are not exceptions in C++ (though they seem to be in Java, brrr).

apta 6y ago

Having worked on large golang code bases, I'd take Java exceptions anytime. golang error handling is not only atrocious (you end up having to manually re-invent exceptions anyway), but also error prone and dangerous.