Is it a good practice to suppress warnings?

Sometimes while writing Java in Eclipse, I write code that generates warnings. A common one is this, which I get when extending the Exception class:

public class NumberDivideException extends Exception {

    public NumberDivideException() {
        super("Illegal complex number operation!");
    }

    public NumberDivideException(String s) {
        super(s);
    }
} // end NumberDivideException

The warning:

The serializable class NumberDivideException does not declare a static final serialVersionUID field of type long.

I know this warning is caused by my failure to... well, it sa开发者_运维技巧ys right above. I could solve it by including the serialVersionUID, but this is a one hour tiny assignment for school; I don't plan on serializing it anytime soon...

The other option, of course, is to let Eclipse add @SuppressWarnings("serial").

But every time my mouse hovers over the Suppress option, I feel a little guilty.

For programming in general, is it a good habit to suppress warnings?

(Also, as a side question, is adding a "generated" serialVersionUID like serialVersionUID = -1049317663306637382L; the proper way to add a serialVersionUID, or do I have to determine the number some other way?)

EDIT: Upon seeing answers, it appears my question may be slightly argumentative... Sorry! Too late for me to delete though...

In the particular case of eclipse, rather than suppress warnings as they happen, I prefer setting up eclipse to emit warnings I care about and automatically ignore all instances of the ones I don't. See Windows -> Preferences -> Java -> Compiler -> Error/Warnings

That's rather specific to Java though, and I find that Java tends to have many more warnings I don't care about than most other languages. In other languages, I usually have all warnings on and fix them as they come up

It's very satisfying to have code compile with out warnings - and when you do get one it then stands out and may alert you to a problem in the code

You shall supress warnings ONLY if you are absolutely sure of what you are doing and it whould be better to have this kind of thing documented for future alterations (java doc comments for example)

this way you hide the warnings you know won´t cause problems and can focus on the ones that will cause you problens

If it's a program you're ever going to look at again, it will pay off to do things 'the right way' -- and that means not suppressing warnings, but fixing them.

For school assignments however, you are often asked to reinvent the wheel/complete trivial tasks, and so you shouldn't feel any qualms about "hacking" stuff together. Unless of course you are graded on coding style...

You should never suppress warnings globally even just one particular kind of warning. You should also set your compiler to be as picky as possible. Warnings are there to tell you about problems that may exist. You can either refactor your code to get rid of them or, in some languages, add some sort of directive to ignore a specific bit of code that causes a specific warning. This will allow you to review a warning and ignore it if you know it is OK.

Wherever practical, suppress warnings only on a particular line, or - at most - a particular file.

Not only does this ensure that warnings that you WEREN'T expecting get through to you, but it serves as an explicit design note - pointing out to the next person editing the code (or yourself in a month's time) that you were aware of the issue, and took a deliberate decision that it was acceptable for this code. That saves the next person from having to evaluate the situation again.

(I don't know enough about Eclipse to make this happen - this is a general principle that applies across languages.)