undefined | Better HN

0 pointsXorNot2mo ago0 comments

I will freely go on the record as saying that there's nothing wrong with exceptions for this exact reason: errors are so common that a function being "pure" is the exception, and that errors-as-value handling invariable turns into an endless chain of something like "if err; return (nil/zero, err)" in every language which tries it.

The same would apply to anytime you have Result types - ultimately its still just syntactic sugar over "if err then...".

What's far more common in real programs is that an error can occur somewhere where you do not have enough context to handle or resolve it, or you're unaware it can happen. In which case the concept of exceptions is much more valid: "if <bad thing here> what do I want to do?" usually only has a couple of places you care about the answer (i.e. "bad thing happened during business process, so start unwinding that process" and many more where the answer is either "crash" or "log it and move on to the next item".

0 comments

kubb2mo ago

Exceptions can be bad if done the wrong way. But the solution isn’t to not deal with it and put it on the programmer. That’s laziness.

The problems are that the signature of functions doesn’t say anything about what values it might throw, and that sometimes the control flow is obscured — an innocuous call throws.

Both of these are solvable.

XorNotOP2mo ago

Sure but that also feels like a compiler problem. The compiler knows everywhere my function can go. So rather then having it just throw an exception - i.e. arbitrary data - on the stack, surely what's really happening is I'm creating a big union of "result | error[type,type,type,type]" which only gets culled when I add my "exception" handling.

My argument here would be, that all of this though doesn't need to be seen unless its relevant - it seems reasonable that the programmer should be able to write code for the happy path, implicitly understanding there's an error path they should be aware of because errors always happen (I mean, you can straight up run out of memory almost anywhere, for example).

kubb2mo ago

I agree, and I think that the simplicity mantra of the early go team caused them to not deal with solvable problems when they had the chance.

They would rather not solve it, thinking that the "programmers will deal with it".

Now they claim it’s too late.

j / k navigate · click thread line to collapse

0 comments

kubb2mo ago

Exceptions can be bad if done the wrong way. But the solution isn’t to not deal with it and put it on the programmer. That’s laziness.

The problems are that the signature of functions doesn’t say anything about what values it might throw, and that sometimes the control flow is obscured — an innocuous call throws.

Both of these are solvable.

XorNotOP2mo ago

kubb2mo ago

I agree, and I think that the simplicity mantra of the early go team caused them to not deal with solvable problems when they had the chance.

They would rather not solve it, thinking that the "programmers will deal with it".

Now they claim it’s too late.

j / k navigate · click thread line to collapse