可以中止属性的设定过程吗

发布于 2024-08-21 17:25:37 字数 490 浏览 5 评论 0原文

我正在使用 C#.NET 进行编程。是否可以中止类属性的设置过程而不引发异常?

这就是我想要做的...

public int RandomProperty
{
    set
    {
     DialogResult answer = new DialogResult();
     answer = MessageBox.Show("This process could take up to 5 min. Are you sure you want to continue?");
     if(answer = DialogResult.No) 
        CancelSet   // Can I do something similar here?
     else
     {
      ...Do set procedure
     }
    }
}

我不认为我可以使用方法(而不是属性),因为我正在使用 propertygrid 设置此值。

I am programming in C#.NET. It is possible to abort the set procedure of a class property without throwing an exception?

Here is what I want to do...

public int RandomProperty
{
    set
    {
     DialogResult answer = new DialogResult();
     answer = MessageBox.Show("This process could take up to 5 min. Are you sure you want to continue?");
     if(answer = DialogResult.No) 
        CancelSet   // Can I do something similar here?
     else
     {
      ...Do set procedure
     }
    }
}

I don't think I can use a method (instead of a property) because I am setting this value with a propertygrid.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

つ低調成傷 2024-08-28 17:25:37

IMO 这根本不是一件好事 - 期望是如果 set 不抛出它分配的值。在执行设置之前在UI(或任何地方)进行测试,或者抛出并处理异常。或者,调用者可能会被一种方法所迷惑:

public bool TrySetRandomProperty(SomeType value) {
    ...
}

该方法返回truefalse来指示它是否发生。您还应该避免将 UI 代码渗透到域逻辑中;也许使用事件让 UI 与用户对话,而不会对调用者造成特定的 UI 实现?

IMO that is simply not a good thing to do - the expectation is that if the set doesn't throw it assigned the value. Test in the UI (or where-ever) before doing the set, or throw and handle an exception. Alternatively, the caller might be less confused by a method:

public bool TrySetRandomProperty(SomeType value) {
    ...
}

which returns true or false to indicate whether it happened. You should also avoid bleeding UI code into domain logic; perhaps use an event to let the UI talk to the user without inflicting a particular UI implementation on the caller?

停滞 2024-08-28 17:25:37

在任何情况下都不应该这样做。属性应该始终快速并且在逻辑上代表某物的属性。理想情况下它永远不应该失败。它当然不应该产生诸如弹出 UI 之类的副作用。您违反了所有这些重要准则。不要这样做。

此外,你的 UI 设计很糟糕。不要事先询问用户“这可能需要一段时间,你确定吗?”如果他们点击“是”,就会惩罚他们漫长的等待。相反,开始操作,如果它没有快速返回,则弹出一个 UI 元素,其中显示进度条和带有取消按钮的预计剩余时间。

您可能应该将长时间运行的操作编写为可以在另一个线程上完全取消的异步方法。

对于此类事情,一个好的架构是让您的方法立即返回一个对象,该对象公开诸如“我仍在运行,这是我已经走了多远”或“我现在完成了,这是结果”之类的事件,或者“我在尝试执行操作时遇到错误,具体情况如下”。该对象还可以公开一个“取消”方法,该方法知道如何与工作线程通信并彻底关闭它。获取该对象的方法的调用者可以决定如何向用户显示 UI。

通过此架构,您可以将 UI 逻辑、异步逻辑和业务流程逻辑清晰地相互分离。这是工作,但它会在以后带来红利。

Under no circumstances should you do any of this. A property should always be fast and logically represent a property of something. Ideally it should never fail. It certainly should not produce side effects such as popping up UI. You're violating all of these important guidelines. Don't do it.

Furthermore, your UI design is bad. Don't ask a user beforehand "this might take a while, are you sure?" and then punish them with a long wait if they click yes. Instead, start the operation, and if it doesn't return quickly, pop up a UI element that shows a progress bar and an estimated time left that has a cancel button.

You should probably write your long-running operation as an asynchronous method that can be cleanly cancelled on another thread.

A good architecture for this sort of thing is to have your method return immediately an object that exposes events like "I'm still running and here's how far along I am", or "I'm done now and here's the result", or "I got an error while attempting to do the operation and here's what it is". That object can also expose a "cancel" method that knows how to communicate with the worker thread and shut it down cleanly. The caller of the method that gets this object can then decide how to display the UI to the user.

With this architecture you separate your UI logic, your asynchrony logic and your business process logic from each other cleanly. This is work, but it pays dividends later.

一抹淡然 2024-08-28 17:25:37

啊。您真的想将用户界面包含在类属性中吗?您不应该在用户界面中进一步进行此检查吗?

Ugh. Do you really want to involve the user interface inside a class property? Shouldn't you do this check further out in the user interface?

情话已封尘 2024-08-28 17:25:37

您当然可以这样编码,只是不设置该字段。

然而,当您将 UI 混合到低级代码中时,您的设计非常糟糕。

在设置属性之前询问问题是一种选择。

You can certainly code it this way, just don't set the field.

However, you've got a very bad design as you are mixing UI into your low-level code.

Asking the question before setting the property is a one option.

凝望流年 2024-08-28 17:25:37

刚从集合中返回。您必须使用私有字段来保存要设置的值,但返回“取消”应该可以做到这一点。

Just return out of the set. You'll have to use a private field to hold the value of what you want to set, but returning in the "cancel" should do it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文