BRAINSTORM: return type of 'exception'

[dsimcha]

== Quote from Russell Lewis (webmaster at villagersonline.com)'s article
> So I was listening to the discussion about opApply in the "lazy" thread.
>   Somebody mentioned that opApply would be better if we could eliminate
> the int return code.
> So I thought, "well, you could make the unusual situations (return,
> break, etc.) exceptions, but that would be too slow..."
> Then I thought, "wouldn't it be cool if the compiler could recognize
> that we had a void return value, and somehow convert the exception into
> a simple return code..."
> Then I thought, "what if we could delcare a function's return type to be
> 'exception'?"
> The idea here is that if you had return type 'exception', then
> exceptions coming out of that function would be returned as return
> values rather than thrown with the ordinary mechanism.  The calling
> function would be responsible for checking that return code and handling
> it properly if an exception were returned.
> So, inside this type of function, "throw" statements would be converted
> (by the compiler) into "return"s.  And when you called a function of
> this type, it would check the return code and throw the proper exception
> if one was returned.  In something like opApply, where you have this
> type of function calling this type of delegate, the compiler-generated
> code would look like opApply does now.
> PROPOSED SYNTAX
> 	exception opApply(exception delegate(ref MyType) dg)
> 	{
> 		<do some looping stuff>
> 			dg(<thing>)
> 			// compiler checks the return code for us!
> 	}
> END SYNTAX
> Thoughts?

I like the back-end compiler optimization part of this for void return types.
However, I don't like the idea of making the programmer responsible for checking
the error code.  The nice thing about exceptions is that if you don't handle an
exception because you believe that it can't happen in your case, then you've
basically got an assert, and if you were wrong and it CAN happen, you'll know
about it fast.  They're also nice when you're writing a quick and dirty prototype,
because the default behavior given bad input (such as a file that doesn't exist)
is to fail in a reasonable way.  Realistically, in a throwaway prototype I would
never bother to check error codes, and this would probably lead to some
frustrating "bugs" that were really caused by bad input.