适用于 C++ 的智能断言应用?

发布于 2024-08-11 20:53:24 字数 415 浏览 2 评论 0原文

定义一个新的宏是否会满足我向用户显示失败断言的需要,并为开发人员提供足够的信息来调试问题,这是否很好?

给用户的消息,什么 用户应该将此消息作为开发人员的最后信息

#define ASSERT(f) \
    do \
    { \
    if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \
        AfxDebugBreak(); \
    } while (0) \

用户应该在我们使用的

MessageBox(_T("Error in finding file."),_T("TITLE"),MB_ICONERROR);

Is it good to define a new macro that craters my need of showing failed assertion to user and with just enough information for developers to debug the issue.

Message for user, what the
user should do with this message at last information for the developer

#define ASSERT(f) \
    do \
    { \
    if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \
        AfxDebugBreak(); \
    } while (0) \

sample message fn that we use,

MessageBox(_T("Error in finding file."),_T("TITLE"),MB_ICONERROR);

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

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

发布评论

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

评论(5

苏辞 2024-08-18 20:53:24

消息框不得向开发人员显示任何信息。开发人员的信息必须保存在某些日志文件中,并且用户要求将文件传输给开发人员。

PS:你的问题太短了。

Message Box MUST NOT show any information for developers. information for developers must be saved in some log-file and user asked for transmit file to developer.

PS: You question is extremely short.

半暖夏伤 2024-08-18 20:53:24

从最终用户的角度来看,我会考虑一些事情。

  • 目标受众是谁?如果您的祖母正在使用此程序,这些断言消息框除了让她感到沮丧之外还会有什么作用吗?
  • 这些断言失败的频率有多高?正常使用一周内的一次断言肯定会证明将其保留在程序中是合理的,但一小时几次只会激怒用户。中间立场显然很难衡量。
  • 您是否考虑过在程序中添加“启用断言”首选项?这样,如果有一些更具技术头脑(且乐于助人)的用户,他们可以显式启用断言并在出现问题时通知您出错;如果某些用户不知道断言是什么或者为什么他们会在您的程序中弹出窗口,他们可以禁用断言并继续愉快地使用您的程序。希望您可以在弹出窗口中添加“不再显示断言失败消息”复选框。

我想说,强制用户弹出断言显然是个坏主意,但允许他们启用或禁用警告将是一个好方法。

There's a couple things I would consider from the end-user's standpoint.

  • Who is the target audience? If your grandmother is using this program, would these assertion messageboxes accomplish anything beyond frustrating her?
  • How frequently would these assertions fail? One assertion during a week of normal usage would certainly justify keeping it in the program, but several an hour would just irritate the user. The middle ground is obviously very difficult to gauge.
  • Have you considered putting in an "Enable Assertions" preference into the program? That way, if there are some more technical-minded (and helpful) users, they can explicitly enable the assertions and inform you when things go wrong; and if some users have no idea what an assertion is or why they are getting popups in your program, they can just disable the assertions and continue to happily use your program. Hopefully, you can put a "Do not show me assertion failure messages anymore" checkbox on the popup.

I'd say that forcing the assertion popups on users would be a plain bad idea, but allowing them to enable or disable the warnings would be a good approach.

方觉久 2024-08-18 20:53:24

就在问这个问题后,我读到了 Andrei Alexandrescu 和 John Torjo 在 中提到的 SMART_ASSERT增强断言。这看起来对我来说是正确的选择,但是该文章中的源链接已损坏,有人可以给我 SMART_ASSERT 的源代码吗?

Just after asking this question I read about SMART_ASSERT mentioned by Andrei Alexandrescu and John Torjo in Enhancing Assertions.This looks like that is right candidate for me, but the link to the source in that article is broken, can someone give me the source code for SMART_ASSERT?

糖果控 2024-08-18 20:53:24

永远不要向用户暴露任何内部结构,除非他们都是程序员,而是使用日志文件和弹出窗口,并建议将这些日志发送(自动)给开发人员。

Never expose any internals to users unless they are all programmers instead use log-files and pop-up with proposition of sending(automatically) those logs to devs.

书间行客 2024-08-18 20:53:24

我不会让用户看到任何真正的调试信息,因为它只会让你的应用程序看起来很成熟。

其次,为什么使用 do-while 循环而不是常规的 {} 作用域?

I would not let users see any real debug info, as it will only make your application look amature.

Secondly, why are you using a do-while loop instead of a regular {} scope ?

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