I have an application that reads a database and outputs alerts to any dependencies that are not being met. My thinking on this issue is "Give the minimum information that points the user to the issue." I have been told by a co-worker that I should be as verbose as possible, printing out the values of the database fields for each field I mention verses giving the minimum message that "field one needs to be less then field two".
我有一个应用程序,它读取数据库并向任何未满足的依赖项输出警报。我对这个问题的看法是“提供指向用户的最小信息”。一位同事告诉我,我应该尽可能地详细,打印出每个字段的数据库字段的值,我提到的最小消息是“字段1需要小于字段2”。
I know that there must be some convention or standard for this issue as it reminds me of compiler errors and warnings. Does anyone know how a compiler messages are are chosen?
我知道这个问题必须有一些约定或标准,因为它让我想起了编译器错误和警告。有谁知道如何选择编译器消息?
What suggestion does the community have for this issue?
社区对此问题有什么建议?
7 个解决方案
#1
2
When writing, know your audience.
写作时,要了解您的受众。
If you're logging warning/error messages for your own consumption, then it's fairly easy: what do you need to know when something goes wrong?
如果您正在为自己的消费记录警告/错误消息,那么这很简单:当出现问题时您需要知道什么?
If you're logging warning/error messages for someone else, then things get tricky. What do they know? What does their mental model of the system look like? What sorts of problems can they solve, and what information do they need to solve them?
如果您正在为其他人记录警告/错误消息,那么事情会变得棘手。他们知道什么?他们的系统心理模型是什么样的?他们可以解决哪些问题,以及解决这些问题需要哪些信息?
Pushing every last scrap of data into a message is punting - at best, the reader will have to wade through irrelevant information in order to find what they need; at worst, they'll become confused and end up making decisions based on the wrong data.
将最后一批数据推送到一条消息中是最好的 - 读者最多只需要浏览不相关的信息以找到他们需要的东西;在最坏的情况下,他们会变得困惑,最终根据错误的数据做出决定。
The compiler analogy is apt: think how annoying it would be if the entire symbol table was dumped along with every warning...
编译器类比很简单:想想如果整个符号表与每个警告一起被转储会有多烦人......
#2
2
I think the key is to be concise. Put as much detail as is required for the reason for the warning to be communicated and nothing more.
我认为关键是要简洁。尽可能详细地说明要传达警告的原因,仅此而已。
#3
1
For normal, day-to-day operation, I give a data validation message that gives enough information that the user can fix the problem, so that the data validates. For example, if I have two fields (fieldA and fieldB) and one of them have to be greater than the other, then I would state that on the validation output, specifying which field is the offending field.
对于正常的日常操作,我提供了一条数据验证消息,该消息提供了用户可以解决问题的足够信息,以便数据进行验证。例如,如果我有两个字段(fieldA和fieldB),其中一个必须大于另一个,那么我会在验证输出上声明,指定哪个字段是违规字段。
For example, if A has to be greater than B, and they supply an answer less than B, then the message would be "fieldA needs to be higher than fieldB"
例如,如果A必须大于B,并且它们提供小于B的答案,那么消息将是“fieldA需要高于fieldB”
That said, I also program a debug mode into my applications (especially the web-applications) which has a verbose mode, telling exactly what's happening with everything. If that's turned on you would see two messages, the user-friendly error, and then "FieldA=XX and FieldB=YY: XX is not greater than YY".
也就是说,我还将调试模式编程到我的应用程序(尤其是Web应用程序)中,这些应用程序具有详细模式,准确地告诉所有事情发生了什么。如果打开,你会看到两条消息,即用户友好的错误,然后“FieldA = XX和FieldB = YY:XX不大于YY”。
That's simplified, but it's the general idea.
这是简化的,但这是一般的想法。
#4
0
I would suggest that you should implement both modes. During normal operation you need a useful but short message. But sometimes things could go wrong and in this case a 'dump' mode which gives the user all possible information is a life saver.
我建议你应该实现这两种模式。在正常操作期间,您需要一条有用但短信息。但有时事情可能会出错,在这种情况下,“转储”模式可以为用户提供所有可能的信息,从而节省生命。
#5
0
I think there are 3 levels of the details of an error message for the 3 typical user groups:
我认为3个典型用户组的错误消息有3个级别:
- The end user. This is a surfer on a web site or an user of a desktop application. He should receive an error message if the problem can not be compensate. It should include the minimum of information. The end user should not receive any information over the system like current configuration and file paths. The end user should contact the administrator. A continuous error id can be helpful that the administrator can find more informations.
- The administrator need more helpful information to solve the problem self. It can include information like table xy not fount or login to database failed.
- The developer: If the administrator can not solve the problem then it will contact the software vendor. In this case the administrator should be able to send a log file that the developer can solve it also if he can not reproduce the problem.
最终用户。这是网站上的冲浪者或桌面应用程序的用户。如果问题无法弥补,他应该收到错误消息。它应该包括最少的信息。最终用户不应该通过系统接收任何信息,如当前配置和文件路径。最终用户应与管理员联系。连续错误ID可能有助于管理员找到更多信息。
管理员需要更多有用的信息来解决问题。它可以包括表xy not fount或登录数据库失败等信息。
开发人员:如果管理员无法解决问题,那么它将联系软件供应商。在这种情况下,管理员应该能够发送开发人员可以解决的日志文件,如果他无法重现问题。
#6
0
The specifics of the content of a log can be discussed, but it is my experience that the level of verbosity will quickly determined during stress test.
If the system can not function properly, it is because you just:
可以讨论日志内容的细节,但根据我的经验,在压力测试期间很快就会确定详细程度。如果系统无法正常运行,那是因为你只是:
- get either too verbose with your logs, or
- did log too often (actually, I believe Jeff himself had a similar problem)
对你的日志过于冗长,或者
记录过于频繁(事实上,我相信杰夫自己也有类似的问题)
Atwood: We were logging in such a way that the log.... during the log call was triggering another log call. Which is normally okay, but with the load that we have, eventually they would happen so close together that there's also a lock. So, there's two locks going on there.
Atwood:我们以这样的方式登录,即日志调用期间的日志....触发另一个日志调用。这通常是好的,但是由于我们拥有的负载,最终它们会发生如此接近以至于还存在锁定。所以,那里有两个锁。
Spolsky: [...] you have a tendency to wanna log everything. But then you just get logs that are, you know, a hundred megabyte per user and you get thirty of them a minute and it can't possibly be analyzed or stored in any reasonable way. So the next thing you have to do is to start culling your logs or just have different levels of debugging, where it's like in high debug mode everything is logged and in low debug mode nothing is logged. And... it's kind of hard to figure out what you really want in a log.
Spolsky:[...]你有想要记录一切的倾向。但是,你只需要获得每个用户100兆字节的日志,并且每分钟可以获得30个日志,并且无法以任何合理的方式对其进行分析或存储。所以你接下来要做的就是开始剔除你的日志或者只是有不同级别的调试,就像在高调试模式下一样,所有内容都被记录下来,而在低调试模式下,没有任何记录。并且......在日志中弄清楚你真正想要的东西是很难的。
Atwood: I mean that, ironically, to troubleshoot this hang, which turned out to be because of logging, we were adding more logging.
阿特伍德:我的意思是,具有讽刺意味的是,要解决此问题,原因是由于日志记录,我们正在添加更多日志记录。
Spolsky: [laughs]
Atwood: The joke just writes itself! The joke just writes itself, right...
阿特伍德:这个笑话只是自己写的!这个笑话只是自己写的,对...
So my point is, when you will run your system in a production-like environment, you should quickly be able to determine if the level of verbosity you choose is sustainable.
所以我的观点是,当您在类似生产的环境中运行系统时,您应该能够快速确定您选择的详细程度是否可持续。
#7
-1
Dealing with errors Vs. warnings first: An error should be for something which violates the standard. A warning should be for something which is allowed, but quite likely isn't what the author intended.
处理错误。警告:错误应该是违反标准的事情。警告应该是允许的,但很可能不是作者的意图。
For example, the W3C Markup Validator will warn about the use of the syntax <br /> in an HTML document. In XHTML this means "A line break", but in an HTML document, while being allowed, actually means "A line break followed by a greater than sign" (even if most browsers don't respect this).
例如,W3C标记验证器将警告在HTML文档中使用语法
。在XHTML中,这意味着“换行”,但在HTML文档中,虽然被允许,但实际上意味着“换行后跟一个大于号”(即使大多数浏览器都不尊重这一点)。
As for verbosity, what is best does depend on who is using the system. Some users would be better with brief messages that they can skim through, while other users (perhaps those less advanced) would find the additional information useful. Without knowing more about who they are, I'd tend towards using a flag (-v is traditional) to let the user select which version they prefer.
至于详细程度,最好的方法取决于谁在使用该系统。一些用户可以更好地使用他们可以浏览的简短消息,而其他用户(可能是那些不太高级的用户)会发现其他信息很有用。如果不了解他们是谁,我倾向于使用标志(-v是传统的)让用户选择他们喜欢的版本。
#1
2
When writing, know your audience.
写作时,要了解您的受众。
If you're logging warning/error messages for your own consumption, then it's fairly easy: what do you need to know when something goes wrong?
如果您正在为自己的消费记录警告/错误消息,那么这很简单:当出现问题时您需要知道什么?
If you're logging warning/error messages for someone else, then things get tricky. What do they know? What does their mental model of the system look like? What sorts of problems can they solve, and what information do they need to solve them?
如果您正在为其他人记录警告/错误消息,那么事情会变得棘手。他们知道什么?他们的系统心理模型是什么样的?他们可以解决哪些问题,以及解决这些问题需要哪些信息?
Pushing every last scrap of data into a message is punting - at best, the reader will have to wade through irrelevant information in order to find what they need; at worst, they'll become confused and end up making decisions based on the wrong data.
将最后一批数据推送到一条消息中是最好的 - 读者最多只需要浏览不相关的信息以找到他们需要的东西;在最坏的情况下,他们会变得困惑,最终根据错误的数据做出决定。
The compiler analogy is apt: think how annoying it would be if the entire symbol table was dumped along with every warning...
编译器类比很简单:想想如果整个符号表与每个警告一起被转储会有多烦人......
#2
2
I think the key is to be concise. Put as much detail as is required for the reason for the warning to be communicated and nothing more.
我认为关键是要简洁。尽可能详细地说明要传达警告的原因,仅此而已。
#3
1
For normal, day-to-day operation, I give a data validation message that gives enough information that the user can fix the problem, so that the data validates. For example, if I have two fields (fieldA and fieldB) and one of them have to be greater than the other, then I would state that on the validation output, specifying which field is the offending field.
对于正常的日常操作,我提供了一条数据验证消息,该消息提供了用户可以解决问题的足够信息,以便数据进行验证。例如,如果我有两个字段(fieldA和fieldB),其中一个必须大于另一个,那么我会在验证输出上声明,指定哪个字段是违规字段。
For example, if A has to be greater than B, and they supply an answer less than B, then the message would be "fieldA needs to be higher than fieldB"
例如,如果A必须大于B,并且它们提供小于B的答案,那么消息将是“fieldA需要高于fieldB”
That said, I also program a debug mode into my applications (especially the web-applications) which has a verbose mode, telling exactly what's happening with everything. If that's turned on you would see two messages, the user-friendly error, and then "FieldA=XX and FieldB=YY: XX is not greater than YY".
也就是说,我还将调试模式编程到我的应用程序(尤其是Web应用程序)中,这些应用程序具有详细模式,准确地告诉所有事情发生了什么。如果打开,你会看到两条消息,即用户友好的错误,然后“FieldA = XX和FieldB = YY:XX不大于YY”。
That's simplified, but it's the general idea.
这是简化的,但这是一般的想法。
#4
0
I would suggest that you should implement both modes. During normal operation you need a useful but short message. But sometimes things could go wrong and in this case a 'dump' mode which gives the user all possible information is a life saver.
我建议你应该实现这两种模式。在正常操作期间,您需要一条有用但短信息。但有时事情可能会出错,在这种情况下,“转储”模式可以为用户提供所有可能的信息,从而节省生命。
#5
0
I think there are 3 levels of the details of an error message for the 3 typical user groups:
我认为3个典型用户组的错误消息有3个级别:
- The end user. This is a surfer on a web site or an user of a desktop application. He should receive an error message if the problem can not be compensate. It should include the minimum of information. The end user should not receive any information over the system like current configuration and file paths. The end user should contact the administrator. A continuous error id can be helpful that the administrator can find more informations.
- The administrator need more helpful information to solve the problem self. It can include information like table xy not fount or login to database failed.
- The developer: If the administrator can not solve the problem then it will contact the software vendor. In this case the administrator should be able to send a log file that the developer can solve it also if he can not reproduce the problem.
最终用户。这是网站上的冲浪者或桌面应用程序的用户。如果问题无法弥补,他应该收到错误消息。它应该包括最少的信息。最终用户不应该通过系统接收任何信息,如当前配置和文件路径。最终用户应与管理员联系。连续错误ID可能有助于管理员找到更多信息。
管理员需要更多有用的信息来解决问题。它可以包括表xy not fount或登录数据库失败等信息。
开发人员:如果管理员无法解决问题,那么它将联系软件供应商。在这种情况下,管理员应该能够发送开发人员可以解决的日志文件,如果他无法重现问题。
#6
0
The specifics of the content of a log can be discussed, but it is my experience that the level of verbosity will quickly determined during stress test.
If the system can not function properly, it is because you just:
可以讨论日志内容的细节,但根据我的经验,在压力测试期间很快就会确定详细程度。如果系统无法正常运行,那是因为你只是:
- get either too verbose with your logs, or
- did log too often (actually, I believe Jeff himself had a similar problem)
对你的日志过于冗长,或者
记录过于频繁(事实上,我相信杰夫自己也有类似的问题)
Atwood: We were logging in such a way that the log.... during the log call was triggering another log call. Which is normally okay, but with the load that we have, eventually they would happen so close together that there's also a lock. So, there's two locks going on there.
Atwood:我们以这样的方式登录,即日志调用期间的日志....触发另一个日志调用。这通常是好的,但是由于我们拥有的负载,最终它们会发生如此接近以至于还存在锁定。所以,那里有两个锁。
Spolsky: [...] you have a tendency to wanna log everything. But then you just get logs that are, you know, a hundred megabyte per user and you get thirty of them a minute and it can't possibly be analyzed or stored in any reasonable way. So the next thing you have to do is to start culling your logs or just have different levels of debugging, where it's like in high debug mode everything is logged and in low debug mode nothing is logged. And... it's kind of hard to figure out what you really want in a log.
Spolsky:[...]你有想要记录一切的倾向。但是,你只需要获得每个用户100兆字节的日志,并且每分钟可以获得30个日志,并且无法以任何合理的方式对其进行分析或存储。所以你接下来要做的就是开始剔除你的日志或者只是有不同级别的调试,就像在高调试模式下一样,所有内容都被记录下来,而在低调试模式下,没有任何记录。并且......在日志中弄清楚你真正想要的东西是很难的。
Atwood: I mean that, ironically, to troubleshoot this hang, which turned out to be because of logging, we were adding more logging.
阿特伍德:我的意思是,具有讽刺意味的是,要解决此问题,原因是由于日志记录,我们正在添加更多日志记录。
Spolsky: [laughs]
Atwood: The joke just writes itself! The joke just writes itself, right...
阿特伍德:这个笑话只是自己写的!这个笑话只是自己写的,对...
So my point is, when you will run your system in a production-like environment, you should quickly be able to determine if the level of verbosity you choose is sustainable.
所以我的观点是,当您在类似生产的环境中运行系统时,您应该能够快速确定您选择的详细程度是否可持续。
#7
-1
Dealing with errors Vs. warnings first: An error should be for something which violates the standard. A warning should be for something which is allowed, but quite likely isn't what the author intended.
处理错误。警告:错误应该是违反标准的事情。警告应该是允许的,但很可能不是作者的意图。
For example, the W3C Markup Validator will warn about the use of the syntax <br /> in an HTML document. In XHTML this means "A line break", but in an HTML document, while being allowed, actually means "A line break followed by a greater than sign" (even if most browsers don't respect this).
例如,W3C标记验证器将警告在HTML文档中使用语法
。在XHTML中,这意味着“换行”,但在HTML文档中,虽然被允许,但实际上意味着“换行后跟一个大于号”(即使大多数浏览器都不尊重这一点)。
As for verbosity, what is best does depend on who is using the system. Some users would be better with brief messages that they can skim through, while other users (perhaps those less advanced) would find the additional information useful. Without knowing more about who they are, I'd tend towards using a flag (-v is traditional) to let the user select which version they prefer.
至于详细程度,最好的方法取决于谁在使用该系统。一些用户可以更好地使用他们可以浏览的简短消息,而其他用户(可能是那些不太高级的用户)会发现其他信息很有用。如果不了解他们是谁,我倾向于使用标志(-v是传统的)让用户选择他们喜欢的版本。