Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: markspace <markspace@nospam.nospam>
Newsgroups: comp.lang.java.programmer
Subject: Re: Interface with implied Constructor
Date: Sun, 21 Jul 2013 13:45:17 -0700
Organization: A noiseless patient Spider
Lines: 104
Message-ID: <kshgtf$q78$1@dont-email.me>
References: <krgpcp$pba$1@speranza.aioe.org> <925adeb1-65b5-4a50-86a8-4f04784f8da0@googlegroups.com> <kri3sj$lnl$1@speranza.aioe.org> <b4g0e8F35pjU1@mid.individual.net> <Qo1Gt.8876$2C2.1824@fx04.iad> <n45ju8laf3gcaqtlerq776rti1jtid53j9@4ax.com> <kscaks$4qd$4@dont-email.me> <b500nlFgqq8U1@mid.individual.net> <kseneh$g77$1@dont-email.me> <fuWGt.180837$hK5.138447@fx15.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 21 Jul 2013 20:39:11 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="fba3415ba68d85d643935af2f52f0b4b"; logging-data="26856"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197GkE0QsrXMdwgYqc64RGgXOofLhFnHIY="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
In-Reply-To: <fuWGt.180837$hK5.138447@fx15.iad>
Cancel-Lock: sha1:a1E2aZHHQgybDQNxp+vFt+bTyDE=
Xref: csiph.com comp.lang.java.programmer:24794

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.