Why catch an exception just to throw it again?

Question

In an webservice I see this code: Whats the point of catch the exception and just throw it again? Do I miss something?

<WebMethod()> _
Public Function dosomething() As Boolean
    Try
        If successful Then
            Return True
        Else
            Return False
        End If
    Catch ex As Exception
        Throw ex
    End Try
End Function

Edit: Thanks for the answers! I thought it was something like that, but wasn't sure If I could/would refactor those away without any implications.

Answer 1

I can think of no reason to do this for functionality. However, it can arise when previously there was some error handling (logging usually) that has been removed, and the developer removed the log handling but did not restructure the code to remove the redundant try/catch.

Answer 2

Probably a bit of code left over from debugging (you'd set a breakpoint on the throw so you could examine the exception in the debugger). I might do something like this if I wanted to log the exception and then pass it up the chain, although I'd probably wrap the exception in another one with a more meaningful (to my application) error message.

Answer 3

Don't do this.

If you absolutely need to rethrow the exception, just use throw; using throw ex; erases the stack trace and is absolutely wrong.

Answer 4

You may want to do it, if you want to catch an exception except a sub-class of it.

e.g.

try{
    // something stupid
}catch(RuntimeException e){
    throw e; //handle it outside
}catch(Exception e){
    // I'm dead
}

Answer 5

One of the architectures (design patterns) I could see this being used is where a transaction is being handled. The function does its work fails and the catch block completes the transaction to a known state (usually a roll back) then throws a user defined exception.

As it stands now, refactor that code to a more sane state.