Bug 30952 - disable a warning with a comment
Summary: disable a warning with a comment
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: All All
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-05 08:47 EST by Nikolay Metchev CLA
Modified: 2009-08-30 02:15 EDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay Metchev CLA 2003-02-05 08:47:43 EST
It would be nice to be able to put a special comment in your code that would 
disable certain warnings shown by the eclipse parser. For example sometimes you 
know that a parameter in a method is not used it would be nice to put 
a "//@param paraname unused" somewhere well defined and cause that task not to 
show in the tasks view. Also it would be nice to have a quickfix that would add 
the appropriate comment.
Comment 1 Philipe Mulet CLA 2003-02-05 17:52:21 EST
Interesting idea. Post 2.1
Comment 2 Boris Pruessmann CLA 2003-03-08 05:16:04 EST
Please _don't_ do this. Everyone who has ever used lint knows that this'll lead
to code that is full of those special comments making it much harder to read. 
Comment 3 Philipe Mulet CLA 2003-03-08 05:33:14 EST
We already have one special tag to recognize non-nls String literals.
Comment 4 Boris Pruessmann CLA 2003-03-08 06:18:37 EST
Correct. We decided to use it and by now our source code is full of those 
comments. I don't want to imagine how it looks when there are NON-PARAM-, NON-
VARIABLE- etc. comments all over the place.

In fact, I doubt that using NON-NLS in first place was a very good decision. 
One can argue that nobody is forced to use those comments. However, if you have 
a policy that stipulates certain compiler settings, developers _will_ use those 
comments to get rid of warnings instead of fixing the real issues. I mean, I 
have seen developers that add NON-NLS- comments to strings by reflex and not 
because the string doesn't need externalization.

If there will be more of those comments, there should be a way in eclipse to 
enforce certain policies to make sure that certain warnings cannot be disabled 
via such comment. If the team decided to have warnings about unused parameters, 
I did so by a certain intend and I don't think that there is a very good reason 
to override this decision.
Comment 5 Stefan Matthias Aust CLA 2003-03-09 05:00:49 EST
You have to balance between the annoyance of false warnings in the task view and
the annoyance of //NO-WARN comments in the code.  The first could lead to
deactivating the warnings altogether which IMHO is worse.  I'd suggest to have
just one "do not warn in this line of code" tag, not an individual tag for each
type of warning though.  It should be a kind of "yea I know this is a deprecated
method in 1.4 but I have to overwrite it 'cause I need to be 1.3 compliant,
don't bother me any more" statement.
Comment 6 Scott Mising name CLA 2003-03-09 19:59:53 EST
It would be useful to add a checkbox that allows you to block future warning 
with the same information. 

IE: warning list shows overriden deprecated methods. You dont want to show them 
for certain sources. When the warning shows up, check the checkbox, and it is 
excluded from the warnings from then on.
Comment 7 Genady Beryozkin CLA 2003-04-22 11:14:49 EDT
I propose to enable/disable warmings for each file, and not for each line.
This way, the comments can be put in the beginning/end of the file, where
they can be easily found and removed.
Comment 8 Eric Rizzo CLA 2004-12-08 11:28:15 EST
I think there need to be options to warning-disable an entire file and/or
individual lines. There are many cases where I'd want to do one or the other and
if only one were provided it is guaranteed there would be requests for the other.
Also, if this is implemented it would be very helpful to make the presence of
such a disabling tag be itself configurable as a warning. That way the disabling
tags can easily be flagged and located.
Comment 9 Genady Beryozkin CLA 2005-05-17 11:39:17 EDT
Can we do that with the @suppresswarning annotation?
Can eclipse process the standard annotations even if the project does not use 1.5?
Comment 10 Philipe Mulet CLA 2005-05-30 05:33:52 EDT
Annotations can only live in Java5 source code.
Comment 11 Michael Michael CLA 2006-06-08 07:28:26 EDT
I need a way to disable certain deprecated warnings.  For example there is a method deprecated in 1.4 but undeprecated in 1.5.  I think people should have the choice, and for those who don't want to have this feature, why do you want to force all of us to not have it?  Just don't use it if you don't want to.  that's what project coding rules are for.
Comment 12 Denis Roy CLA 2009-08-30 02:15:36 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.