为什么 DevExpress Treelist 定期抛出 HideException？
我一直在使用 DevExpress Filter TreeList 代码，并且很好奇为什么它会抛出 DevExpress.Utils.HideException。
我的理解是，异常是昂贵的，应该谨慎使用，并且仅在某些情况下使用，但下面的代码片段显示我们总是抛出 HideException ，而没有任何特定事件或代码被触发。
来自 FilterTreeList.cs
private void OnMouseDown(object sender, MouseEventArgs e)
{
if ( e.Button != MouseButtons.Left )
return;
TreeListHitInfo hitInfo = ((TreeList)sender).CalcHitInfo(e.Location);
if ( hitInfo.HitInfoType == HitInfoType.Column )
{
ColumnInfo colInfo = ((TreeList)sender).ViewInfo.ColumnsInfo[hitInfo.Column];
GridFilterButtonInfoArgs filterButtonInfo = GetFilterButtonInfoArgs(colInfo);
if ( filterButtonInfo != null && filterButtonInfo.Bounds.Contains(e.Location) )
{
filterButtonInfo.State = ObjectState.Pressed;
((TreeList)sender).InvalidateColumnHeader(hitInfo.Column);
throw new HideException();
}
}
为什么他们在这里抛出 HideException ，它有什么好处？
I have been working with the DevExpress Filter TreeList code and am curious about why it throws a DevExpress.Utils.HideException.
My understanding is that exceptions are expensive and should be used sparingly and only in certain situations, but the code snippit below shows that we are always throwing the HideException without any specific events or code being tripped.
From FilterTreeList.cs
private void OnMouseDown(object sender, MouseEventArgs e)
{
if ( e.Button != MouseButtons.Left )
return;
TreeListHitInfo hitInfo = ((TreeList)sender).CalcHitInfo(e.Location);
if ( hitInfo.HitInfoType == HitInfoType.Column )
{
ColumnInfo colInfo = ((TreeList)sender).ViewInfo.ColumnsInfo[hitInfo.Column];
GridFilterButtonInfoArgs filterButtonInfo = GetFilterButtonInfoArgs(colInfo);
if ( filterButtonInfo != null && filterButtonInfo.Bounds.Contains(e.Location) )
{
filterButtonInfo.State = ObjectState.Pressed;
((TreeList)sender).InvalidateColumnHeader(hitInfo.Column);
throw new HideException();
}
}
Why are they throwing a HideException here, and what benefit does it serve?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它是一种用于清理控件环境的程序流机制。虽然与普通代码相比，异常确实是昂贵的（典型示例是在循环中使用 FormatExceptions 将字符串转换为整数 - 因此需要 TryParse 类型方法），但与 UI 中的主要更改相比，从数据库等，它们非常便宜且易于维护。
您引用的演示代码正是这种情况：控件即将刷新其全部内容。最终用户单击特定图标来执行特定操作 - 根本不会“总是”抛出异常。我对这个示例代码的唯一不满（我强调这是示例代码）是该操作是在鼠标按下时完成的，而不是在鼠标松开时完成的。
我猜这个论点是“异常可以用于这种宏程序流，还是我们应该制定一个硬性规则，即它们只能用于错误报告？”但这完全是另一个问题。
更新
WinForms 团队告诉我：
因此，大约一个月后，它将引起考古学的兴趣。
It's a program flow mechanism for clearing up the control's environment. Although it is true that exceptions are expensive compared to normal code (the archetypal example is using FormatExceptions in a loop that converts strings to ints -- hence the need for TryParse type methods), when compared to major changes in the UI, fetching data from the database, etc, they are very cheap and easy to maintain.
The demo code you're quoting is that exact scenario: the control is about to refresh its entire contents. The end-user has clicked on a specific icon to perform a specific action -- the exception is not "always" being thrown at all. My only beef with this sample code (and I stress that it is sample code) is that the action is being done at mouse down and not at mouse up.
I guess the argument is "could exceptions be used for this kind of macro program flow, or should we institute a hard-and-fast rule that they should only be used for error reporting?" But that's a whole other question.
Update
I'm told by the WinForms team:
So it'll be of archaeological interest in a month's time or so.
我想说这是
I would say it's
在我看来，他们正在使用异常来控制程序流程。文档中的一些注释表明它会阻止调用基类方法。这太糟糕了。 .NET 框架无一例外地执行此操作的方法是 OnMouseWheel() 使用的 HandledMouseEventArgs 类。
Looks to me like they are using exceptions to control program flow. Some note in the docs that it prevents the base class method from getting called. That's pretty awful. The .NET framework way to do this without exceptions is the HandledMouseEventArgs class, used by OnMouseWheel().