Try Catch handled at top of process

Question

if I do this:

try 
{
    //code
}
catch (Exception)
{
    throw;
}

Does the Exception go up with all its information? The idea is to handle errors at the top of the app. There I'd execute some SQL sp to fill the admin's table so he's aware of exceptions.

I want to store Exception.Message and the source (method, function, whatever..) of the exception. But I don't know how to refer to "where" the exception happened. Is it Exception.Source? Exception.TargetSite?

Thanks.

How many questions are you asking? It's not clear if this is all one question or if it's two different ones. What are you trying to accomplish? — Mark Byers, Jul 17 '12 at 11:53
it's one question, leading to a doubt that one may want to solve. Thanks. — Daniel Sh., Jul 17 '12 at 11:54
Why are you passing exceptions all the way back up the application stack? Is there a reason for this? — Simon Whitehead, Jul 17 '12 at 11:54
Please take a look at this post : http://stackoverflow.com/questions/730250/is-there-a-difference-between-throw-and-throw-ex — callisto, Jul 17 '12 at 11:56
@callisto Yes, I dont want the error's origin to be "handleexception", that's why I use throw; — Daniel Sh., Jul 17 '12 at 11:59
@SimonWhitehead no specific reason, just to make the code lighter since all they want is errors to be written down in a table for later usage. Any suggestion?. Thanks. — Daniel Sh., Jul 17 '12 at 12:01
So their requirement is every single exception that occurs be logged? What happens if the exceptions can be handled gracefully by the application? — Simon Whitehead, Jul 17 '12 at 12:08
@SimonWhitehead Well, that would be something "extra" from me since it's not required. All I need to provice is the app not to crash. If some error generates problems within app continuity over time I suppose they will put me to solve it. So you have a point there. — Daniel Sh., Jul 17 '12 at 12:10

score 1 · Accepted Answer · answered Jul 17 '12 at 11:57

1

The type of Exception will tell you what kind of exception it is (IndexOutOfRangeException, SqlException, etc) which you would react too accordingly:

try 
{
    //code
}
catch (SqlException ex)
{
    // Handle code
}
catch (IndexOutOfRangeException ex)
{
    // Handle code
}
catch (Exception ex)
{
    // Handle code
}

As to where it is happening... you should be enclosing exception-prone areas with a try catch and not large code chunks. This way you will know where the exception derives from.

answered Jul 17 '12 at 11:57

Dave New

38,496
59
215
394

that info, I mean "where" it's hapenning, is in ex.Source? thanks – Daniel Sh. Jul 17 '12 at 12:05
Are you looking for the stack trace? ex.Message will give you the error description. ex.Source will give you the object name that caused the error. – Dave New Jul 17 '12 at 12:08
that's it, the stack trace. Thanks – Daniel Sh. Jul 17 '12 at 12:14
Just a minor nit, you should only handle exception you can actually recover from. For example with an IndexOutOfRangeException you should let go by, because you should always know *a priori* that your index is within bounds; receiving this exception means you have a fatal flaw in your logic. SqlException you could handle safely, given context. – user7116 Jul 17 '12 at 12:31

score 1 · Answer 2 · answered Jul 17 '12 at 11:58

The Short answer is yes: just calling throw passes everthing regarding the exception up.

throw ex resets the stack trace (so your errors would appear to originate from HandleException)
throw doesn't - the original offender would be preserved.

(quoted from Mark Gravell)

Try Catch handled at top of process

2 Answers2