获取方法中出现异常的参数 [英] Get parameters for which exception came in a method

问题描述

我正在一个大项目中工作，一个错误日志文件就是记录所有错误。

现在我记录的错误很好。

但是有些错误/验证不应该记录在我的错误日志文件中。

ex：客户代码必须是5个字符。

这些类型的异常不应该记录那里..

我也想知道哪个函数出错，以及哪些函数产生错误...

ex ex我已经给出了下面的代码如果我除一个0的值我正在除以异常..

这个通过使用Targetsite（）方法得到我得到的方法。

并使用stacktrace我得到哪一行我收到错误。



但现在我的要求是我想知道传递给该方法的参数...请问有什么方法告诉我......

hi ,i am working in a big project in that one error log file is there to log all errors in that.
now i am logging errors that is fine.
but there are some errors/validations which should not log in my errorlog file.
ex: Customer code must be 5 characters.
these type of exceptions should not log there..
and also i want in which function error came and for what parameters that function producing the error...
for ex i have given below code if i divide a value with 0 i am getting divide by o exception..
in this by using Targetsite() method i am getting in which method i am getting.
and by using stacktrace i am getting in which line i am getting error.

but now my reguirement is i want to know the parameters also passed to that method ...is there any way tell me please......

Public Sub nextgo() Handles btnnext.Click
   Try
      dividethat(0, 10)
      txtpwd.Text = Nothing
   Catch ex As Exception
      Dim er As System.Reflection.MethodBase = ex.TargetSite()
      txtuname.Text = er.Attributes
   End Try
End Sub
Public Sub dividethat(ByVal x As Integer, ByVal y As Integer)
   Dim z As Integer = y / x
End Sub

推荐答案

pullareddyS写道：

pullareddyS wrote:

它需要花费太多时间来检查哪个页面以及产生错误的参数...

it is taking too much time to check from which page and for which parameters the error is produced…

你的想法是使用 System.Exception.StackTrace （就是你使用的）实际上已经足够好了。如果您使用类 System.Diagnostics.StackTrace 执行自己的代码跟踪，而不是使用此属性（只是一个字符串），则可以改进跟踪：

http://msdn.microsoft.com/en-us/library /system.diagnostics.stacktrace.aspx [ ^ ]。



例如，您可以通过编程方式分析堆栈，而无需进行无意义的字符串解析，例如，只提取您的相关信息我真的想把你的日志放进去，并跳过你在问题中提到的那些与验证相关的步骤。



另外，你不应该害怕花太多时间 。在合理编写的代码中，异常很少发生。即使你使用异常处理用户输入错误（而不是消毒输入，我在解决方案2的评论中反对，请参阅），它不会经常发生，也不会经常发生用户输入。 :-)而且您可以在本地处理这些异常，从而有效地从日常处理中删除日志。所以，无论你做什么，浪费的时间都不会有什么重大意义。



当然，你应该避免许多初学者的常见谬误：在当地处理异常，挫败了技术的目的。所有异常都应该在每个线程中处理，但只能在很少的战略创建的代码点中处理，我通常将其称为能力点，其中您的代码上下文允许您以合理的方式处理异常。在所有其他方法中，您应该简单地让异常传播。这是技术的核心要点：不要处理各地的例外情况。请看我过去的答案：

当我运行一个应用程序时，会遇到如何处理这个问题的异常？ [ ^ ]，

投掷。 .then ... rethrowing [ ^ ]，

异常详情：系统。 Runtime.InteropServices.COMException：由于以下错误，检索具有CLSID {0006F03A-0000-0000-C000-000000000046}的组件的COM类工厂失败：... [ ^ ]，

处理类库（dll）中的异常 [ ^ ]，

捕获例外 [ ^ ]，

错误记录和屏幕截图。 [ ^ ]，

保持交流#windows表单应用程序运行尽管有任何未处理的异常 [ ^ ]，

如何制作一个在滚动条到达底部时停止的循环 [ ^ ]。



（对不起，很多点都在重复。这正是我记录中的内容。希望你能看到我的观点;这不是太多的阅读。 :-)）

-SA

Your idea to use System.Exception.StackTrace (is that what you use) is actually good enough. You can improve tracing if, instead of using this property, which is just a string, you perform tracing by your own code using the class System.Diagnostics.StackTrace:
http://msdn.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx[^].

For example, you can progammatically analyze the stack without pointless string parsing and, say, extract only relevant information which you really want to put in your log and skip all those validation-related steps you mentioned in your question.

Also, you should not be afraid of "taking too much time". Exception, in a reasonably written code, happens rarely. And even when you use exception for handling, say, user input errors (instead of sanitizing of input, which I argued against in my comment to Solution 2, please see), it does not happen often, not more often then the user types. :-) And you can locally handle those exceptions effectively removing then from your general handling with logging. So, whatever you do, the time wasted cannot be anything significant.

Of course, you should avoid the very common fallacy of many beginners: handling exceptions too locally, which defeats the purpose of the technology. All exceptions should be handled in each thread, but only in very few strategically created points of code, which I usually call the "points of competence", where your code context allows you to handle an exception in a sensible way. In all other methods, you should simply let exceptions propagate. This is the hole point of the technology: not to handle exceptions everywhere. Please see my past answers:
When i run an application an exception is caught how to handle this?[^],
throw . .then ... rethrowing[^],
Exception Details: System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error:...[^],
Handling exceptions in class library (dll)[^],
Catching an Exception[^],
Error Logging and Screen Shot.[^],
Keep a c# windows form application running despite any unhandled exception[^],
How do i make a loop that will stop when a scrollbar reaches the bottom[^].

(Sorry, many points are repeated. This is just what I have in my records. Hope you will see my points anyway; it's not too much reading. :-))

—SA

简单地说你不能。为什么？因为异常是非常普遍的。它们可以在许多不同的情况下抛出，在大多数情况下，你甚至无法分辨，它们都涉及到任何参数。情况很少见。

你有没有抛出异常？您是否在异常中抛出了对任何具体参数的引用？如果是，您可能创建了一些消息。如果您捕获异常，您也可以收到消息。这就是你能做的一切。

如果你想记录验证消息（我真的无法想象在日志中使用这些条目），你必须制作一个完整的验证机制，为你做这件事。内置任何东西都不能满足这个要求。输入验证不应该抛出异常，这是正常的业务流程，人们会犯错误。应用程序应该驱动用户纠正错误。例外是更严重的问题。

如果用户不应输入零，请不要让他输入零。



另一件事：有一些方法可以在异常处理程序中反映方法参数，但是获取值确实非常重要，并不适用于生产情况。你必须在另一个层面上管理它。

Simply you can't. Why? Because an exception is something very general. They can be thrown in many different situations, in most of them you can't even tell, that there was any parameter involved at all. It is rarely the case.
Have you ever thrown an exception? Did you put in the exception thrown a reference to any concrete parameter? If yes, you probably created some message. If you catch the exception, you can get the message as well. That's much everything you can do.
If you want to log validation messages (I can't really imagine the use of such entries in a log), you have to make a whole validation mechanism that will do this for you. There is nothing built in that will satisfy this requirement. An input validation should not throw exceptions, it is a normal business flow, that people do mistakes. The application should drive the user to correct the mistake. Exceptions are for more serious issues.
If user should not enter zero, don't let him enter zero.

An other thing: there are ways to reflect the method arguments in an exception handler, but getting the values is really-really hart, and not meant for production situations. You have to manage this on an other level.

如果你需要错误日志中的函数参数，你需要在该例程中进行错误处理，为什么不这样做：

If you need the arguments of the function in the error log you need to have the error handling in that routine, why would you not do this:

Public Sub nextgo() Handles btnnext.Click
   Try
      dividethat(0, 10)
      txtpwd.Text = Nothing
   Catch ex As Exception
      Dim er As System.Reflection.MethodBase = ex.TargetSite()
      txtuname.Text = er.Attributes
   End Try
End Sub
Public Sub dividethat(ByVal x As Integer, ByVal y As Integer)
   Try
      Dim z As Integer = y / x
   Catch ex as Exception
      'Do your logging here
   End Try
End Sub

或者更好的是，清理你的输入参数秒。例如，您可以这样做：

Or, better yet, sanitize your input arguments. For example you could do this:

Public Sub dividethat(ByVal x As Integer, ByVal y As Integer)
   If x = 0 Then
      Throw New DivideByZeroException("x must not equal zero")
   End If

   Dim z As Integer = y / x
End Sub

例外情况不应用于控制程序流程。如果您可以确定将发生异常，那么您需要自己抛出异常，而不是传递错误数据。这将帮助您确定错误的位置。

Exceptions should not be used to control program flow. If you can determine that an exception will occur then you need to throw an exception yourself, not pass bad data around. This will help you determine where an error is.

这篇关于获取方法中出现异常的参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！