记录错误代码设计,需要输入
所以,我陷入了一个小问题。我很好奇是否有人愿意对此设计提供一些额外的意见。
我有一个 ILog 接口,其中有两种用于设计的错误代码日志记录部分的方法。 FlagError 和 GetErrorCode; FlagError 在整数上设置一个位,每个位代表抛出了某个错误。GetErrorCode(这将是 Main 方法的返回值)返回该整数。
我首先推测在每个应用程序中使用enum
来包含可能的错误代码列表。
但问题是,我究竟如何以友好的方式向用户传达错误代码“XYZ”表示应用程序在执行过程中遇到了这些非正常状态?
日志接口: (写入方法有重载)
interface ILog
{
void FlagError (int errorCode);
int GetErrorCode ();
#region Other ILog Methods
void WriteError(string message);
void WriteWarning(string message);
void WriteInfo(string message);
void WriteDebug(string message);
#endregion
}
日志类:
abstract class Log : ILog
{
public void
FlagError (int errorCode)
{
if (errorCode == 0 || errorCode == int.MinValue || errorCode != (errorCode & -errorCode))
{
throw new IndexOutOfRangeException ();
}
if ((m_errorCode & errorCode) == errorCode)
return;
m_errorCode += errorCode;
}
public int
GetErrorCode ()
{
return m_errorCode;
}
#region Other ILog Methods
}
我推测在每个枚举值上使用一个属性以及该错误的描述,然后只需进行一些处理或其他操作来帮助将错误代码“解析”为人类可读的描述。
但我不知道,有什么想法吗?
So, I'm stuck on a little problem. I was curious if anyone had some extra input they might be willing to give on this design.
I have an ILog interface which has two methods exposed for the Error Code logging part of the design. FlagError and GetErrorCode; FlagError sets a bit on an integer, each bit representing that a certain error was thrown., GetErrorCode (which would be the return value for the Main method) returns that said integer.
I speculated at first at using an enum
in each application to contain a list of possible ErrorCodes.
But the problem is, how exactly would I relay to the users that error code 'XYZ' represents that the application hit these un-normal states during execution in a friendly way?
ILog Interface:
(Write Methods have overloads)
interface ILog
{
void FlagError (int errorCode);
int GetErrorCode ();
#region Other ILog Methods
void WriteError(string message);
void WriteWarning(string message);
void WriteInfo(string message);
void WriteDebug(string message);
#endregion
}
Log Class:
abstract class Log : ILog
{
public void
FlagError (int errorCode)
{
if (errorCode == 0 || errorCode == int.MinValue || errorCode != (errorCode & -errorCode))
{
throw new IndexOutOfRangeException ();
}
if ((m_errorCode & errorCode) == errorCode)
return;
m_errorCode += errorCode;
}
public int
GetErrorCode ()
{
return m_errorCode;
}
#region Other ILog Methods
}
I speculated using an attribute on each enum value with a description of that error, and then just having a little process or something to help 'parse' the error code into a human readable description.
But Idk, any Ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
感谢你们的评论,我考虑了它们,并找到了一个解决方案(虽然不是最好的),可以满足我需要完成的任务。
我最终创建了一个添加到每个枚举值的描述属性,然后在枚举上创建了一个“GetDescription”扩展方法。然后,每当我标记一个错误时,它的描述就会被写到控制台/文件/窗口或 w/e.
我想我应该公开更多 ILog 的方法才能找到这个解决方案。
新的 FlagError 方法:
GetDescription 扩展方法:
Description 属性:
如果有人有任何其他输入,我很乐意听到。
Thanks for your comments guys, I took them into consideration, and found a solution that (while not the best) will work for what I need done.
I ended up created a Description attribute that I added to each enum value, then creating a 'GetDescription' extension method on Enum. Then, whenever I flag an Error, its description gets writen out to the console/file/window or w/e.
I suppose I should have exposed some more of ILog's methods for this solution to have been found.
New FlagError Method:
GetDescription Extention Method:
Description Attribute:
If anyone has any additional input, I would love to hear it.
我可能会使用枚举,将这些值和日志记录代码放入每个应用程序都可以调用的通用程序集中。它可能不是有史以来最优雅的解决方案,但它可以完成工作,让您继续处理更重要的事情 - 比如不会引发太多错误的良好核心业务逻辑:-)。
另一种选择可能是将错误代码和人类可读的描述放入配置文件中。这样您就可以灵活地改进错误消息。我从来没有尝试过,但现在想起来,我发现它在很多情况下都是一个真正的好处。
I would probably go with the enum, placing those values and the logging code into a common Assembly that can be called by each application. It might not be the most elegant solution ever, but it gets the job done and let's you move on to more important things -- like good core business logic that doesn't throw too many errors :-).
Another option might be to put the error codes and human-readable descriptions into a config file. That way you would have some flexibility for improving the error messages. I've never tried that, but now that I think of it, I can see it being a real boon in many situations.