Re: Interface with implied Constructor
On 7/21/2013 12:18 PM, Arved Sandstrom wrote:
To the larger question, which I snipped, I'd still have the constructor
throw exceptions. It's just a method, and in this case a failure to
build is significant - it rates an exception. I don't know why it would
screw up scoping: I'd typically have the happy path inside the "try". If
you make your "try" blocks too small then you're defeating the purpose
and introducing unnecessary "is this thing null" checks.
I wonder if the syntax is an issue here. Part of the reason lambdas are
being developed is to correct a "horizontal problem and vertical
problem" in Java code. That is, it takes a fair number of lines of
source code to create a fairly simple anonymous class, and that's seen
as a problem by a lot of people.
Perhaps something that removes some of the "vertical problem" in try
catch statements would be useful. Transforming this:
public Object someMethod( Object... params ) {
try ( stuff... )
{
more stuff...
}
catch( stuff ) {
}
}
Into something like this:
public Object someMethod( Object... params ) {
stuff...
more stuff...
return;
catch( stuff ) {
}
}
Might remove some of the visual clutter in using try catch statements.
Obviously this only works for top-level try-catch statements, but I
think keeping things simple is the best idea.
Moving to a different idea, I also wonder if it's possible to define a
lighter weight exception method that's more suited to "a quick
check/non-return value" than building a full exception, which I believe
can be very heavy weight (like, an order of magnitude more expensive to
return an exception rather than a simple value).
So maybe something like this
public void : int checkedMethod( Object... params ) {
...
}
Where the "void:" syntax is taken to mean "nothing, or" some return
value. The idea here is that the compiler should insert the test for
"void" (nothing, the error value) so the programmer doesn't have to
remember to test a flag or some special return code. This provides the
light weight advantages of a return code with out the fragility of a
programmer having to remember to test the return code.
I'm not sure exactly how to implement this, though. Some thoughts:
1. If the programmer doesn't test the return value, then an Error is
thrown. This builds a stack frame, because you want to know who isn't
testing for return values.
2. A special if test is allowed to test for invalid return values. This
provides fine grained testing.
3. A special catch pattern is allowed to test for "void:" return values.
This provides for coarser grained recovery when you want all
statements with a void: return value to do the same thing.
Alternately #1 could be a compile error instead of a runtime check.
Actually, this might be the better idea.
#2 Example
int i;
if( void : i = checkedMethod() ) {
// "void:" return code, error processing here...
} else {
// i was assigned a value here
}
#3 Example
try {
int i = checkedMethod();
// lots o' statements...
} catch( void ) {
// error processing here
}
....Just random thoughts by Y.T.