3 ms·

In general, if you are benchmarking exceptions, it's a sign that you don't understand exceptions. Exceptions are not meant to replace error codes, that you use

by pif 2y ago

In general, if you are benchmarking exceptions, it's a sign that you don't understand exceptions. Exceptions are not meant to replace error codes, that you use to get a detailed picture of the current environment. They are rather like a kind of assertions, where you don't actually care too much what happens next, because the exception being thrown means someone, somewhere, somehow, has already fuc*ed up.

not_the_fda 2y ago
Yep, exceptions are to be exceptional, i.e. rare.
kllrnohj 2y ago
Look at the error rates they are testing. A 0.1% exception rate, which is certainly something that'd be "rare", starts to happen an awful lot when you have a program that's using 128 cores, and 5th generation Epyc can push 384 threads in a single socket now.
- pif 2y ago
  > Look at the error rates they are testing. I am sure they have very good reasons to keep working on this issue. That's why I started my comment with "in general".
ryandrake 2y ago
> Exceptions are not meant to replace error codes Just to state the obvious, this is a design philosophy (one of many) and not something imposed by the language. And reasonable people can disagree about whether it's a good one. I think where a lot of engineers go wrong is where they go crazy baking exception-throwing into their logic and error handling code, leaving a beautiful "happy path" in their code, but they are not disciplined about actually catching and handling the exceptions. If you're going to go all in on throwing, then you need to go all in on catching. Otherwise your product is just going to be full of unhandled crashing. A couple projects worth of this, and a developer will start to think "hmm, exceptions are bad, I agree we shouldn't use them!" Which is how we get blanket company policies against using any exceptions at all.

3 ms·

In general, if you are benchmarking exceptions, it's a sign that you don't understand exceptions. Exceptions are not meant to replace error codes, that you use

by pif 2y ago

not_the_fda 2y ago
Yep, exceptions are to be exceptional, i.e. rare.
kllrnohj 2y ago
Look at the error rates they are testing. A 0.1% exception rate, which is certainly something that'd be "rare", starts to happen an awful lot when you have a program that's using 128 cores, and 5th generation Epyc can push 384 threads in a single socket now.
- pif 2y ago
  > Look at the error rates they are testing. I am sure they have very good reasons to keep working on this issue. That's why I started my comment with "in general".
ryandrake 2y ago
> Exceptions are not meant to replace error codes Just to state the obvious, this is a design philosophy (one of many) and not something imposed by the language. And reasonable people can disagree about whether it's a good one. I think where a lot of engineers go wrong is where they go crazy baking exception-throwing into their logic and error handling code, leaving a beautiful "happy path" in their code, but they are not disciplined about actually catching and handling the exceptions. If you're going to go all in on throwing, then you need to go all in on catching. Otherwise your product is just going to be full of unhandled crashing. A couple projects worth of this, and a developer will start to think "hmm, exceptions are bad, I agree we shouldn't use them!" Which is how we get blanket company policies against using any exceptions at all.