Re:Lies we tell ourselves to keep using Golang
by mumblemumble on Saturday April 30, 2022 @11:10AM
(#31216622)
I could believe that, but implementing JVMs is such a very specific use case, far removed from what most programmers do day-to-day. Not just because it's a VM. Because you're implementing a pre-existing specification, so you're not at liberty to make your own design decisions around something like classloader semantics. It feels like a red herring example to me. "Here's how we should think about dealing with error conditions in 2022." "But what if I've got a spec that forces me to do it 1994-style?"
[ Parent
| on HN ]
Re:Lies we tell ourselves to keep using Golang
by kaba0 on Saturday April 30, 2022 @11:29AM
(#31216754)
There is nothing inherent to JVMs here, it is just the all around most common error type. It simply don’t make sense to handle many type of errors at call site, because it misses the big picture and for these, return types are not a good fit.
Re:Lies we tell ourselves to keep using Golang
by mumblemumble on Saturday April 30, 2022 @11:40AM
(#31216855)
So, the idea is basically that of the impureim sandwich: push everything that can fail out to the periphery. If it's difficult to handle errors at the call site, it's a sign that the call site is in the wrong place.