Re:Lies we tell ourselves to keep using Golang
by kaba0 on Saturday April 30, 2022 @02:09AM
(#31213781)
I just gave you an example from the top of my head. Here is another more realistic one, which occurred to me during the time I wrote a toy JVM: a Java class file contains a constant pool with different kinds of types. During the loading process this pool can be references by other entities as well, but they require the necessary type. Assuming verified byte code, this will be the case, but if we care about verification as well then you will quickly get into the situation where you simply can’t handle “during the loading of this class’s nth method, one of the constant pool references were of incorrect type”. It can’t be handled at method loading (or even more nested), and panicking is not the correct behavior (you only don’t want to load the given class). So you have to manually bubble it up for no benefit.
[ Parent
| on HN ]
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?"
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.