Get parameters for which exception came in a method

Question

0.00/5 (No votes)

See more:

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......

VB

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

Posted 19-Oct-13 1:56am

pullareddy S

Updated 19-Oct-13 2:48am

phil.o

v4

Add a Solution

3 solutions

Solution 1

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.

Posted 19-Oct-13 3:21am

Zoltán Zörgő

Updated 19-Oct-13 3:23am

v2

Solution 2

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:

VB

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:

VB

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.

Posted 19-Oct-13 4:18am

Ron Beyer

Comments

Sergey Alexandrovich Kryukov 19-Oct-13 22:25pm

This well-known statement, "Exceptions should not be used to control program flow", is very questionable and very fuzzy. First of all, why do you call some instruction flow a "control flow", but not the exception throwing and propagation? In my opinion, this statement is somewhat dogmatic and probably deviate from the original works on exceptions (to best of my knowledge, related to works by Barbara Liskov et al, and the CLU language). One typical example is processing of wrong input. Why not thrown exception instead of sanitizing? In many situations, doing integer division without check is much more productive, from the standpoint of cleaner code (no redundant checks), with less monkey work on programming and better performance. I am very much against such sanitizing. It does not really make programming safer.

The advice "not pass bad data around" is much wiser...

—SA

pullareddy S 21-Oct-13 0:19am

Actually i have given a sample code above.
in my application i have one method which is common for all forms.
there are nearly 100s of places where my method is calling...
in my method i am getting some error and i am logging that error...
if i log the parameters also passed to that method i can easily find from which page it is calling. otherwise it is taking too much time to check from which page and for which parameters the error is produced....so is there any way to find this easily....

Sergey Alexandrovich Kryukov 21-Oct-13 0:45am

Okay, I tried to answer. Please see Solution 3. Unfortunately, in you code, there is nothing about exception handling, so I had to speculate on your approach as far as I could understand it. If you have to, please ask your follow-up questions or clarify.
—SA

Ron Beyer 21-Oct-13 10:52am

I 5'd yours... my statement about control flow means using exceptions to control how the program operates (if exception x then y). In the world of the software I write exceptions are really bad, especially if you just "let them happen", since control and automation software should have a 100% uptime. The philosophy I work with is handle what you can and pass the rest up, but at no time should you let the program just throw exceptions where the windows handler pops up (Continue, quit, etc).

Not only is it confusing for the user but it may leave the software in an indeterminate state (did what I ask actually happen, or not). Imagine not santizing input and writing invalid data to a nuclear control rod actuator, or in my world telling a valve to go to some bad position and sinking an oil rig. This isn't usually a problem if you are writing a data entry system or a calculator, but there are mission critical software where exceptions are bad things, so I usually go with don't pass bad data around, sanitize immediately.

Sergey Alexandrovich Kryukov 21-Oct-13 11:22am

Thank you, but your text makes me suspect that you might misuse exception mechanism in some ways... :-)
And yes, exception mechanism is designed not to allow anything to be left in indeterminate state. Yes, if you are working with a nuclear reactor, not sanitizing input and relying on exception propagation will be much safer then sanitizing. This is what exceptions were designed for. Just one argument: exception mechanism is universal, it is elaborated and tested for all cases at once, and sanitizing would mean manually-written ad-hoc code where a human beings can seed a programming bugs... Universal always safer then ad-hoc.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-10-20T18:43:00

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

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