例如,我收到此编译器警告,
永远不会使用'Company.SomeControl.SearchClick'事件。
但是我知道它被使用是因为评论它会让我感觉像是在尝试使用这个事件的XAML页面的20个新警告!
是什么给出的?有没有办法摆脱这个警告?
答案 0 :(得分:120)
这似乎是warning 67,因此可以通过以下方式进行抑制:
#pragma warning disable 67
不要忘记尽快(在事件声明之后)使用:
恢复它#pragma warning restore 67
但是,我会再次检查并确保您在某处提升事件,而不是只是订阅。当您注释掉事件时,编译器会发出20个警告而不是20个错误的事实也是可疑的......
关于此警告还有an interesting article,特别是它如何应用于接口;关于如何处理“未使用”事件有一个很好的建议。不幸的是,这个链接现在(暂时?)已经死了,但重要的部分是:
正确的答案是明确你对活动的期望,在这种情况下,什么都不是:
public event EventHandler Unimportant { add { } remove { } }
这将干净地抑制警告,以及额外的编译器生成的正常事件的实现。并且作为另一个额外的好处,它促使人们思考这种无所事事的实现是否真的是最佳实现。例如,如果事件不是那么不重要而不支持,那么依赖于该功能的客户端可能会在没有它的情况下失败,最好明确指出缺少支持并通过抛出一个快速失败例外:
public event EventHandler Unsupported { add { throw new NotSupportedException(); } remove { } }
当然,在没有某些功能部分的情况下可以有效实现的接口有时表明接口没有最佳的内聚性,应该分成单独的接口。
答案 1 :(得分:74)
如果您被迫从接口实现事件,您的实现不需要您可以执行以下操作以避免警告。
public event EventHandler CanExecuteChanged { add{} remove{} }
答案 2 :(得分:14)
第二种最好的方法是imho清楚地说明如果有人试图订阅它就抛出异常而不支持该事件。
public event RoutedEventHandler SearchClick
{
add { throw new NotSupportedException(); }
remove { }
}
作为此处的变体,您还可以将add
和remove
方法留空以静默忽略对事件的订阅。
最好的解决方案是重构代码,如果可能的话,可能会将事件的声明提交给实现者。
作为最后的手段,你也可以像这样禁用警告
#pragma warning disable 67
public event RoutedEventHandler SearchClick;
#pragma warning restore 67
答案 3 :(得分:2)
您还可以执行以下操作:
public event EventHandler MyEvent = delegate {}
答案 4 :(得分:1)
编译器显然不知道它正在XAML代码中使用。尝试在事件定义中禁止警告。
另外,请确保您实际上是在某处举办活动。
答案 5 :(得分:1)
你可以压制个别警告。
\Program.cs(13,20): warning CS0219: The variable 'foo' is assigned but its value is never used
在这种情况下,CS0219是关于已分配但未使用的变量的警告。您可以使用/ nowarn:0219标志,也可以在项目的属性窗格中添加错误编号(在“Build”下,记住删除前导CS)。请记住此类的所有警告。
答案 6 :(得分:1)
或者您可以将<NoWarn>67</NoWarn>
添加到项目中
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<NoWarn>67</NoWarn>
</PropertyGroup>