www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - BRAINSTORM: return type of 'exception'

reply Russell Lewis <webmaster villagersonline.com> writes:
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?
Jan 13 2009
next sibling parent Benjamin Shropshire <none anon.com> writes:
Hello Russell,

 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.
[...]
Thoughts?
 
An interesting idea. Might be of particular use if you have a function (or a stack of them) that throws a lot it could result in a major speed boost.
Jan 13 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Russell Lewis (webmaster 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.
Jan 13 2009
parent Russell Lewis <webmaster villagersonline.com> writes:
dsimcha wrote:
 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.
I think you're missing the point of what I'm saying. What I'm suggesting is that when you call a function with return type "exception," the compiler would automatically check the return code for you, and auto-throw the exception if one is returned. It's the syntax of exceptions, with the execution speed of return codes.
Jan 14 2009