5.1.1 file separator warning

In one of my methods, 5.1.1 gives an illegal file separator warning on
the "-/" public IllegalOptionValueException(Option opt, String value) { //noinspection ConditionalExpression super("Illegal value '" + value + "' for option " + (opt.shortForm() != null ? MessageFormat.format("-/",
opt.shortForm()) : "") +
"--" + opt.longForm());
option = opt;
this.value = value;
}

It is not being used as a file separator, but as a message format string. Is this something we might see fixed in 5.2/6.0?

Scott

--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

7 comments
Comment actions Permalink

typo

In article <scott-1785FE.14542507062006@mail.intellij.net>,
Scott Ellsworth <scott@alodar.com> wrote:

In one of my methods, 5.1.1 gives


a hardcoded

file separator warning on
the "-/" > > public IllegalOptionValueException(Option opt, String value) { > //noinspection ConditionalExpression > super("Illegal value '" + value + "' for option " + > (opt.shortForm() != null ? MessageFormat.format("-/",
opt.shortForm()) : "") +
"--" + opt.longForm());
option = opt;
this.value = value;
}

It is not being used as a file separator, but as a message format string. Is
this something we might see fixed in 5.2/6.0?


Obviously, I can just turn the warning off, but / has a role in format
strings, and so should probably not be just killed wherever it is found.

--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

0
Comment actions Permalink

Hello Scott,

Please file a JIRA bug for this.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"

SE> In one of my methods, 5.1.1 gives an illegal file separator warning
SE> on the "-/" SE> SE> public IllegalOptionValueException(Option opt, String value) { SE> //noinspection ConditionalExpression SE> super("Illegal value '" + value + "' for option " + SE> (opt.shortForm() != null ? MessageFormat.format("-/",
SE> opt.shortForm()) : "") +
SE> "--" + opt.longForm());
SE> option = opt;
SE> this.value = value;
SE> }
SE> It is not being used as a file separator, but as a message format
SE> string. Is this something we might see fixed in 5.2/6.0?
SE>
SE> Scott
SE>


0
Comment actions Permalink

Hello Scott,

...sorry, I see now that the bug has already been filed.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"

SE> In one of my methods, 5.1.1 gives an illegal file separator warning
SE> on the "-/" SE> SE> public IllegalOptionValueException(Option opt, String value) { SE> //noinspection ConditionalExpression SE> super("Illegal value '" + value + "' for option " + SE> (opt.shortForm() != null ? MessageFormat.format("-/",
SE> opt.shortForm()) : "") +
SE> "--" + opt.longForm());
SE> option = opt;
SE> this.value = value;
SE> }
SE> It is not being used as a file separator, but as a message format
SE> string. Is this something we might see fixed in 5.2/6.0?
SE>
SE> Scott
SE>




0
Comment actions Permalink

Dmitry Jemerov wrote:

...sorry, I see now that the bug has already been filed.


http://www.jetbrains.net/jira/browse/IDEA-7881
Current state "to be discussed". What can be done to improve this inspection, whose description states: "This inspection reports any instances of the forward (/) or backward (\) slash in a string or character literal"?

Bas

0
Comment actions Permalink

Honestly, this is one inspection I always turn off. It just returns too many false positives to be useful. I can't really come up with any creative heuristics to improve it, either, sorry.

0
Comment actions Permalink

In article <c8a8949ddd4d38c85910df475a1e@news.jetbrains.com>,
Dmitry Jemerov <yole@jetbrains.com> wrote:

Hello Scott,

Please file a JIRA bug for this.


Filed as 7881.


--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"

SE> In one of my methods, 5.1.1 gives an illegal file separator warning
SE> on the "-/" > SE> > SE> public IllegalOptionValueException(Option opt, String value) { > SE> //noinspection ConditionalExpression > SE> super("Illegal value '" + value + "' for option " + > SE> (opt.shortForm() != null ? MessageFormat.format("-/",
SE> opt.shortForm()) : "") +
SE> "--" + opt.longForm());
SE> option = opt;
SE> this.value = value;
SE> }
SE> It is not being used as a file separator, but as a message format
SE> string. Is this something we might see fixed in 5.2/6.0?
SE>
SE> Scott
SE>


--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

0
Comment actions Permalink

In article <8747857.1150103741916.JavaMail.itn@is.intellij.net>,
Colin Fleming <no_reply@jetbrains.com> wrote:

Honestly, this is one inspection I always turn off. It just returns too many
false positives to be useful. I can't really come up with any creative
heuristics to improve it, either, sorry.


In my bug report, I suggested white and black lists. Any US format date
is going to trip it, as is any string like either/or.

After all, we know that a MessageFormat is not going to used as a path
name, in reasonable code, so this usage is safe. Most other things that
take a string - map keys, and the like, are also safe by inspection.

Contrawise, we know that certain usages - File, the string constructors
for streams, etc. - are always unsafe.

The vast middle ground can be handled with a checkbox, or more cleverly
with user-definable white/black lists to add methods to the 'creates a
file' list. Catching the obvious ones might be good enough, and not
triggering on strings only sent right to a MessageFormat constructor,
etc., might miss many cases.

Virtually every class I have that handles date objects has a passel of
x/y/z dates in the unit tests, so this is not entirely academic.

I suspect that the number of methods that create a file out of a string
is fairly short, but I cannot prove that. I do know that as it is, this
one triggers too many false positives to be usable for me and my code at
the present time. (I can see it being useful for others; just not for
me.)

Scott

--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

0

Please sign in to leave a comment.