Avoid exception throwing in performance-sensitive code

Post by ilyt » Thu, Dec 22, 2022, 7:39 PM UTC

rightbyte wrote: post #155

ilyt wrote: post #128

Earlier quoted context omitted.

And it is still opaque where it goes to the programmer when they see it in code. The fact you can use tools to find where it might land (yeah, no shit, you can do same for goto...) is just a mitigation to the problem.

It unwinds the call stack until a catch. It is the same "problem" as not knowing where a return will return to.

Post by MrYellowP » Thu, Dec 22, 2022, 8:20 PM UTC

Post by gthrowaway52 » Thu, Dec 22, 2022, 9:18 PM UTC

groestl wrote: post #143

gthrowaway52 wrote: post #137

Earlier quoted context omitted.

I'm talking about unchecked exceptions. It's not about what is possible it's about what patterns a language encourages. It feels like we've lost the thread of discussion. - You say there is no difference between unchecked exceptions and Go's errors - I say yes there is since Go forces users to handle errors explicitly - You say that's not technically true in all cases. OK. Yes. I should have said "nudges users" inste…

> You say there is no difference between unchecked exceptions and Go's errors Where do I say that? I say that Go programmers, in 99.9% of cases, do manually what exceptions do automatically. In terms of cumbersome, error values are the equivalent of checked exceptions. The equivalent of runtime exceptions are panics.

  * 4 cases where the error is just returned
  * 1 case where the error is returned only if it matches a certain type (otherwise logged)
  * 1 case where the error is logged as a warning.
  * 1 case where the error is logged, some metric is incremented, and then execution continues as usual. (a fail-open authentication check)
  * 1 case where the error is returned as different error type.
  * 1 case where the error is returned, but only after accessing the result (this is a strange design / antipattern), and annotating it with a human-readable explanation.
  * 1 case where the error is treated as a boolean condition, and is not returned. (the error condition is "does not exist").

Post by MrYellowP » Thu, Dec 22, 2022, 9:57 PM UTC

carlmr wrote: post #170

papito wrote: post #159

Earlier quoted context omitted.

Absolutely. Even after "compressing" my code as much as possible, it looks as if 2/3 of a Go program is pure error handling and no business logic. I just don't understand this militant objection toward exceptions now. Even back in the days of slower virtual machines and crappier hardware, we were fine , and now it's code red! Get rid of exceptions! Performance! This is in an era of tech where everyone is building BAD…

>it looks as if 2/3 of a Go program is pure error handling and no business logic. This is exactly why it's good. It forces developers to think about things outside the happy path business logic. And it does this at the point where they know best what such an error could mean. Proponents of exceptions let their users catch the exceptions they overlooked. If you ask me Go is not forcing this enough, the ML style Result…

Post by kortilla » Fri, Dec 23, 2022, 4:22 AM UTC

ilyt wrote: post #128

kortilla wrote: post #112

Earlier quoted context omitted.

This is not correct, a “comes-from” statement would still be the same behavior as a goto except it’s defined at the label and there is no “goto” at the departure line. Exceptions are just “goto whatever catch is in the call stack”. It’s still completely obvious when you see a throw statement that it can throw, and static analysis can tell you exactly what can be thrown by each function.

And it is still opaque where it goes to the programmer when they see it in code. The fact you can use tools to find where it might land (yeah, no shit, you can do same for goto...) is just a mitigation to the problem.