Hacker News Reader

Comment by chrisseaton | Hacker News Reader

I also use exceptions for control-flow and I feel no shame about it. It's often the best (most concise, most performant, most understandable) solution to a problem, in my eyes.

View on HN

Most concise: absolutely. Most performant: never. Most understandable: yes, but only if you are cognizant of which call paths can result in an exception and which can’t (i.e. until your code base becomes too large or you’re not the one that wrote it).

> Most performant: never.

I disagree. An exception can be faster than manually unwinding a set of nested scopes.

Most exceptions, at least in the JVM where this is commonly debated, will incur a penalty of building up the exception and unwinding the call stack. What aspect of performance are you using as an example?

An exception thrown and caught within a compilation unit is effectively a goto. It can translate into nothing more than a jcc instruction, or even nothing at all if it's unconditional. This can be higher performance in practice than threading through a set of Either-style return objects.

Throwing exceptions may be the most concise, but handling them rarely is.

But most importantly, static type systems lose the ability to infer what's coming so these may turn out to be really pesky problems.

You are probably looking for continuations. For many languages exceptions are the nearest approximation.

Personally I have no problem with your approach on the semantic level, but most compiler/interpreter developers consider all exceptional paths as cold as it gets: performance can be "interesting" if you take a lot of them.

Reply on news.ycombinator.com