commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [lang] Revisiting empty statements one more time (last time I promise)
Date Mon, 04 Jul 2005 17:22:50 GMT
How about:

try
{
...
} catch (SomeException ignored) {
 // We do nothing here because the try block checked
 // the widget and logged an error in the fizbang.
}

i.e. use a special variable name that can then be checked in the compiled code.

S.
On 7/4/05, Gary Gregory <ggregory@seagullsoftware.com> wrote:
> Hello:
> 
> I am against using a lone ";". IMHO I think that what shows up in an AST
> is irrelevant in this case and actually a problem with the source
> checking tool. Let's think about the real problem, which I claim is
> this:
> 
> try {
>  // a
>  // bunch
>  // of
>  // stuff
> } catch (SomeException e) {
> }
> 
> My claim: Undocumented empty blocks and especially empty catch blocks
> are a BAD THING. I have Eclipse set up to give a compile warning on
> "undocumented empty blocks" and on "empty statements". Of course, not
> everyone uses Eclipse and whatever source-checking we use tools will not
> have the same features as Eclipse.
> 
> What you really want, I claim, is this:
> 
> } catch (SomeException e) {
>  // We do nothing here because the try block checked
>  // the widget and logged an error in the fizbang.
> }
> 
> Allowing the following is no good IMO as there is no explanation:
> 
> } catch (SomeException e) {
>  ;
> }
> 
> And this is no good either IMO:
> 
> } catch (SomeException e) {
>  ;
>  // We do nothing here because the try block checked
>  // the widget and logged an error in the fizbang.
> }
> 
> I want a source checking tool to tell me about undocumented empty blocks
> because that is a maintenance problem. As long as there is no comment,
> there is a problem IMO. Allowing solo-; is just plain old confusing to
> me and does NOT add any value to the source.
> 
> As I've stated before, because some tools need to have the source
> massaged a certain way is not a good reason to muck up the source, it
> just points to a deficiency in the tool.
> 
> I hope the above convinces folks too ;-)
> 
> Gary
> 
> > -----Original Message-----
> > From: Steven Caswell [mailto:steven.caswell@gmail.com]
> > Sent: Monday, July 04, 2005 9:17 AM
> > To: Jakarta Commons Developers List
> > Subject: [lang] Revisiting empty statements one more time (last time I
> > promise)
> >
> > Gary and Stephen (and anyone else who might care ;)
> >
> > I'd like to take one more stab at convincing you guys that an empty
> > statement denoted by a semicolon would be a better approach to
> > indicate no action than just using a comment. I promise I'll move on
> > if this is not convincing enough.
> >
> > So here we go:
> > - Empty statement is defined by the language so while it may look odd
> > it is in fact a valid Java statement
> > - Since it is a legal Java statement, it is parsable and shows up in
> > ASTs. Comments are discarded and do not show up in ASTs
> > - Any tool that uses an AST approach to examining source constructs
> > (such as PMD) can be told to look for and handle an empty statement.
> > Tools that use ASTs cannot be told to look for comments.
> >
> > IMHO, having the statement parsable and recognizable by tools gives
> > the most flexibility at a pretty small price. The empty statement
> > doesn't affect logic at all, and doesn't affect performance in the
> > tests I've done. It seems a small price to pay (a bit of adjustment in
> > reading the code) for the benefit.
> >
> > If a line with a single semicolon is not acceptable, is there some
> > other parsable construct that would be?
> >
> > Thanks for the indulgence.
> >
> > --
> > Steven Caswell
> > steven.caswell@gmail.com
> >
> > Take back the web - http://www.mozilla.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message