Whoa... RE's, very fancy! :-) I am not being really serious: An even more complicated solution would be to use whatever Eclipse uses to check for such things.
G > -----Original Message----- > From: Steven Caswell [mailto:[EMAIL PROTECTED] > Sent: Monday, July 04, 2005 11:57 AM > To: Jakarta Commons Developers List > Subject: Re: [lang] Revisiting empty statements one more time (last time I > promise) > > It could possible be done using the GenericIllegalRegexp check. I'm > not a regexp guru so I'm not sure if an appropriate regexp could be > written, but knowing how powerful regexps are I wouldn't be surprised. > > On 7/4/05, Gary Gregory <[EMAIL PROTECTED]> wrote: > > > } catch (SomeException ignored) { > > > > Interesting thought! Somehow, I do not think that checkstyle can do > > that. Can it? > > > > Gary > > > > > -----Original Message----- > > > From: sebb [mailto:[EMAIL PROTECTED] > > > Sent: Monday, July 04, 2005 10:23 AM > > > To: Jakarta Commons Developers List > > > Subject: Re: [lang] Revisiting empty statements one more time (last > > time I > > > promise) > > > > > > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > > 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 > > > > > [EMAIL PROTECTED] > > > > > > > > > > Take back the web - http://www.mozilla.org > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Steven Caswell > [EMAIL PROTECTED] > > Take back the web - http://www.mozilla.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
