24

I'm hoping this is straightforward. I work on a large code-base, the overall quality is good, but occasionally you get some of these:

try { // Calls a .NET remoting method. } catch { throw; }

Note there is no finally logic and the catch does not specify any exceptions or do anything other than what I've provided above. However, I know that catching and re-throwing can alter the call-stack in the exception details. What I'm not sure about is if this behaviour is here specifically because of a .NET remoting call.

Is it safe to remove this try-catch? So far as I can see, it is, but I thought I'd double check for any odd behaviour first.

Improve this question
3
  • 2
    @Dan Curious why you think the question change was required? Commented Jun 29, 2011 at 8:38
  • 1
    Although changing the title is a delicate thing to do, I tend to edit them when I think it can be more searchable. google.com/?q=can+i+remove+empty+catch+with+throw now points to your question as the top answer, and I'm sure this is the query people would type more likely than your original title. Commented Jun 29, 2011 at 8:44
  • Fair enough, had a suspicion it was for searching. Commented Jun 29, 2011 at 8:46

4 Answers 4

Reset to default
22

Rethrowing as you've shown it shouldn't change the call stack, unless there's something very special about remoting exceptions. (I know there are some special aspects, but I don't think they come into play here.) This is the kind of thing which does lose information:

catch(Exception e) { throw e; // Not throw; }

My guess is that some developer has included this just so they can put a breakpoint on the throw line. I would get rid of it.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Using just throw can still alter the stack trace if the exception was thrown in the same stack frame as the throw statement - in this case the line number is reset to the line of the throw statement (rather than the line the exception was originally thrown from)
It has been rid, all I need now is an inconspicuous defect number to check it in against :-)
15

As far as I know, catch (Exception ex) { throw ex } resets the stack-trace. And just catch { throw; } does not.

So if you don't perform any additional logic on error, e.g. logging, I don't know any reason to not remove that catch.

Improve this answer

Comments

5

In certain situations related to code access security the catch-rethrow clause can be a necessary security feature. But I doubt it applies here. Especially since no sane person would use this pattern without adding a comment.

The point of it is to prevent exception filters from running while having increased privileges.

A few related articles:

http://blogs.msdn.com/b/shawnfa/archive/2005/03/31/404320.aspx
http://msdn.microsoft.com/en-us/library/8cd7yaws(v=VS.100).aspx
http://www.pluralsight-training.net/community/blogs/keith/archive/2005/03/31/7149.aspx

Seems to be obsolete since .net 2:
Impersonation and Exception Filters in v2.0

Improve this answer

1 Comment

It isn't the case for us, as we don't use CAS. However, interesting information, thanks.
1

While, in most cases, it probably is redundant/unnecessary code, try { .. } catch { throw; } can suppress compiler optimizations and JIT method inlining. This is mostly seen in call-stack traces.

Thus, there "could" be a side-effect that is relied on elsewhere.

Arguably, the 'error' would be in reliance on this implementation detail, especially without explicit documentation about such expected behavior.. and especially since such is not a guarantee.

See Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks which predated even this old question.

While the code seems redundant, the try-catch code won't be eliminated during compilation either.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.