4 ms·

Here are some ways exceptions are objectively worse, so that you can be a more thoughtful person: * Very noisy * Do not survive network boundaries * can but

Here are some ways exceptions are objectively worse, so that you can be a more thoughtful person: * Very noisy * Do not survive network boundaries * can but often do not survive thread boundaries * lack important context * easy to ignore * obscures control flow * difficult to handle * in practice, rarely handled * poor quality messages

kaba0 4y ago
> Very noisy Are you really claiming this under a goddamn Go thread where every third line is error handling? > Do not survive network boundaries Well, depends on what you mean here. Do you mean something like RPC? Because there are implementations that can throw an exception for that. I fail to see how is it different with returning an error value, that doesn’t survive network boundaries in itself either. I fail to come up with any example where exceptions are worse than error return types in the context of threads. come on, exceptions give you a stack trace with the whole history of what got called from where. How is that worse than your “file missing” error without any explanation? > easy to ignore Checked exceptions are a thing. But it is enough to handle them higher up and it will be handled one way or another, while it is much easier to simply fail to handle an err. > in practice, rarely handled I can just as well claim that go-style error handling is more often then not not handling properly the issue at hand, and is most definitely not tested for the error case. A bubbled up exception stopping the program/at least a given thread handling a request is a much better outcome then silent failure. > poor quality messages They get as high or low quality messages as one wants. I prefer a proper stacktrace with line numbers over a single obscure line I might occasionally be able to debug by grepping a code base.
- philosopher1234 4y ago
  I’m not talking about exceptions in theory, which you are completely right about. I’m talking about how exceptions are actually used in practice. You can claim “they should do it differently” but I think you would be ignoring that the design of exceptions is the reason they are not handled/networked/etc. I could go into more detail about your points and it might be interesting, but I am drunk. EDIT: re the noise point, I’m talking about the actual exception when it is read by a developer in a debugging context, not the lines of code dedicated to processing it.

kaba0 4y ago

> Very noisy Are you really claiming this under a goddamn Go thread where every third line is error handling? > Do not survive network boundaries Well, depends on what you mean here. Do you mean something like RPC? Because there are implementations that can throw an exception for that. I fail to see how is it different with returning an error value, that doesn’t survive network boundaries in itself either. I fail to come up with any example where exceptions are worse than error return types in the context of threads. come on, exceptions give you a stack trace with the whole history of what got called from where. How is that worse than your “file missing” error without any explanation? > easy to ignore Checked exceptions are a thing. But it is enough to handle them higher up and it will be handled one way or another, while it is much easier to simply fail to handle an err. > in practice, rarely handled I can just as well claim that go-style error handling is more often then not not handling properly the issue at hand, and is most definitely not tested for the error case. A bubbled up exception stopping the program/at least a given thread handling a request is a much better outcome then silent failure. > poor quality messages They get as high or low quality messages as one wants. I prefer a proper stacktrace with line numbers over a single obscure line I might occasionally be able to debug by grepping a code base.

philosopher1234 4y ago
I’m not talking about exceptions in theory, which you are completely right about. I’m talking about how exceptions are actually used in practice. You can claim “they should do it differently” but I think you would be ignoring that the design of exceptions is the reason they are not handled/networked/etc. I could go into more detail about your points and it might be interesting, but I am drunk. EDIT: re the noise point, I’m talking about the actual exception when it is read by a developer in a debugging context, not the lines of code dedicated to processing it.