代码之家  ›  专栏  ›  技术社区  ›  Chris Cooper

压制警告是一个好的做法吗?

  •  3
  • Chris Cooper  · 技术社区  · 15 年前

    有时在Eclipse编写Java时,我编写生成警告的代码。一个常见的是这个,我在扩展 Exception 班级:

    public class NumberDivideException extends Exception {
    
        public NumberDivideException() {
            super("Illegal complex number operation!");
        }
    
        public NumberDivideException(String s) {
            super(s);
        }
    } // end NumberDivideException
    

    警告:

    可序列化类numberDivideexception未声明long类型的静态final serialversionUid字段。

    我知道这个警告是由于我没有…上面写着。我可以通过包括 serialVersionUID ,但这是学校一个小时的小作业;我不打算很快连载……

    当然,另一个选择是让eclipse添加 @SuppressWarnings("serial") .

    但每次我的老鼠在 Suppress 选项,我有点内疚。

    对于一般的编程来说,抑制警告是一个好习惯吗?

    (另外,作为一个附带问题,正在添加一个“generated” 序列号 喜欢 serialVersionUID = -1049317663306637382L; 添加一个 序列号 ,或者我必须用其他方法来确定这个数字?)


    编辑:看到答案后,我的问题似乎有点争论…对不起的! 不过,太晚了,我无法删除…

    6 回复  |  直到 14 年前
        1
  •  4
  •   hamishmcn    15 年前

    在没有警告的情况下编译代码是非常令人满意的,当你得到一个警告时,它会很突出,并可能提醒你代码中的问题

        2
  •  6
  •   Michael Mrozek    15 年前

    在eclipse的特定情况下,与其在警告发生时抑制警告,不如设置eclipse以发出我关心的警告,并自动忽略那些我不关心的警告的所有实例。 偏好-gt;java>编译器& gt;错误/警告

    这对Java来说是相当具体的,我发现Java倾向于有更多的警告,我不关心大多数其他语言。在其他语言中,我通常会打开所有警告并在它们出现时修复它们

        3
  •  2
  •   dinho    14 年前

    只有当你完全确定自己在做什么时,你才可以不受警告。 这样做会更好地记录将来的更改(例如Java文档注释)

    这样你就隐藏了那些你知道不会引起问题的警告,并且可以把注意力集中在那些会引起你问题的警告上。

        4
  •  1
  •   Jared Forsyth appas    15 年前

    如果这是一个你会再看一次的程序,它将以“正确的方式”来做事情——这意味着不是压制警告,而是修复它们。

    然而,在学校作业中,你经常被要求重新发明轮子/完成琐碎的任务,所以你不应该对一起“黑客”的事情感到任何不安。当然,除非你是按编码方式评分的…

        5
  •  0
  •   Tom Cabanski    15 年前

    您永远不应该在全局范围内禁止警告,即使只是一种特定的警告。您还应该将编译器设置为尽可能挑剔。警告是用来告诉你可能存在的问题。您可以重构代码以消除它们,或者在某些语言中,添加某种指令以忽略导致特定警告的特定代码位。这将允许您查看警告,并忽略它,如果你知道它是好的。

        6
  •  0
  •   Oddthinking    15 年前

    在可行的情况下,仅在特定行或最多在特定文件上禁止显示警告。

    这不仅确保了你没有预料到的警告能够传达给你,而且还作为一个明确的设计说明——向下一个编辑代码的人(或者一个月后的你自己)指出你意识到了这个问题,并慎重地决定这是可以接受的为了这个密码。这样就省去了下一个人再次评估情况的麻烦。

    (我对eclipse的了解还不足以实现这一点——这是跨语言应用的一般原则。)