Why catch an exception just to throw it again?

Related searches

In a webservice I see this code:

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

What's the point of catching the exception and just throwing it again? Do I miss something?

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.

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.

vb.net - Why catch an exception just to throw it again?, So, instead of specifying the two different exceptions that are thrown by the That is much easier to find and handle than an exception that only� Second, if you just catch and re-throw like that, I see no added value, the code example above would be just as good (or, given the throw ex bit, even better) without the try-catch. However, there are cases where you might want to catch and rethrow an exception.

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.

7 Common Mistakes You Should Avoid When Handling Java , What is the correct Java™ programming best practice to catch, print, and Please try again later or use one of the other support options on this page. but the stack trace and message will simply point to the ServletException which The correct way to catch and re-throw an exception is to pass the caught� When an exception is caught, we can perform some operations, like logging the error, and then re-throw the exception. Re-throwing an exception means calling the throw statement without an exception object, inside a catch block. It can only be used inside a catch block.

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.

Best Practice: Catching and re-throwing Java Exceptions, ICanThrowException();. } catch (Exception ex). {. Log(ex);. throw ex;. } exception without losing the original stack trace is to just do throw and don't pass the exception object. It works by first capturing the exception and then throwing it again. try { statements that can throw exceptions} catch (exception-type identifier) { statements executed when exception is thrown} Here, you place the statements that might throw an exception within a try block. Then you catch the exception with a catch block. Here are a few things to note about try statements: You can code more than one catch block.

One of the architectures (design patterns) I could see this being used in 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) and then throws a user-defined exception.

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

How to rethrow exception correctly in .Net, I just announced the new Learn Spring course, focused on the But sometimes in the catch block, we need to throw the same exception again. 3.throw: Throw keyword is used to transfer control from try block to catch block. 4.throws: Throws keyword is used for exception handling without try & catch block. It specifies the exceptions that a method can throw to the caller and does not handle itself. 5.finally: It is executed after catch block. We basically use it to put some common

Not only is the try/catch pointless, but so is the IF. The whole function could be reduced to one line:

return successful

At which point, why bother? Why not just test "successful" instead of calling the function?

Well, okay, it's a Web Method, I guess you need the function just to give Ajax or whomever a handle.

(Yes, I'm aware my answer is 7 years late. I just stumbled across this when searching for something entirely unrelated.)

Wrapping vs Rethrowing Exceptions, As a side note, there's a C# 6 feature called Exception Filters that will make CA1031 slightly more valid again since then you will be able to properly, properly, properly filter the exceptions you want to catch, and there's less reason to write an unfiltered catch (Exception).

When throwing an exception, we can either throw a new exception, like in the preceding example, or a caught exception. try-catch Blocks. A more common approach would be to use a try-catch block to catch and handle the arising exception:

The following example illustrates exception handling for async methods. To catch an exception that an async task throws, place the await expression in a try block, and catch the exception in a catch block. Uncomment the throw new Exception line in the example to demonstrate exception handling.

Mistake 2: Catch unspecific exceptions. The severity of this mistake depends on the kind of software component you’re implementing and where you catch the exception. It might be ok to catch a java.lang.Exception in the main method of your Java SE application. But you should prefer to catch specific exceptions, if you’re implementing a

  • Which is another reason why I would wrap it as an inner exception if I needed to do this for logging.
  • Why? Just throw the original exception. Logging should not change or alter anything.
  • To add my own semantics to the exception. Ex. I get a SqlException because I attempt to insert a row with a duplicate primary key. In my method I know what kind of object and what key value is being inserted. I can write a better exception message yet still retain all the information.
  • This has nothing to do with logging then. Different concept.
  • Exactly the pattern I have seen as well
  • But you still don't want to call "throw e". You want "throw" instead. Calling "throw e" drops the stack information up to that point, and it is dangerous.
  • The throw e; is obviously wrong but aside from that this is an interesting idea. Not sure if there is a use case for it though....
  • And you also swallowed the general Exception so nobody knows about it.
  • @Quarrelsome: No, just wrong. There is no wisdom or knowledge to be gained from this.