[Groxx]

Interesting... I was just coming to the conclusion that such a thing would be handy, as so many things use exceptions as a way of, essentially, returning multiple values. It's rampant - add an item to a set where it already exists, and it throws. Which costs a lot compared to returning false due to the stack-unwinding, but is more flexible. Typically though, the stack-unwinding is entirely unnecessary, the class / message is more than enough to determine the source of the problem. And such a thing would turn try/catch blocks into a loosely-coupled implicit delegate system, which strikes me as fantastically useful.

[kragen]

> Which costs a lot compared to returning false due to the stack-unwinding

The relative costs are dependent on the language implementation. longjmp() in C is only roughly as expensive as a normal function return, but of course setjmp() costs an extra two or three function calls' worth. And in many interpreters, exceptions are basically free.

(Except on MacOS, where setjmp() and longjmp() are an order of magnitude slower because they involve system calls.)

I had a discussion with a mainframer a couple of years back about what kinds of things people did in assembly that aren't reflected in C. One interesting technique he mentioned was incrementing the return address in case of error returns, so the function actually had two different possible points to return to; the calling code would look something like this (x86 version):

        CALL SOMEROUTINE
        JMP 1f
        JMP ERROR
    1   ; continue with normal processing

In case of error, the routine bumped its return address by the size of a jump instruction before returning to the JMP ERROR instruction.

Such a pattern would be awfully disconcerting if you weren't used to it, of course.

Multiple return values were, of course, another thing he mentioned. Any caller-saved register can double as an additional return value.