locked
Why THROW an exception? RRS feed

  • Question

  • Usually we often catch an exception and show exact error details to user. But why sometimes throw is used and exception is explicitly thrown.

    What happens when we throw an exception and when to explicitly throw an exception.

    Sunday, November 30, 2014 5:34 PM

Answers

  • You throw an exception from a subroutine when you want to inform its caller that something unexpected went wrong. For example, you write a subroutine that imports a file into your database. The file is supposed to have a specific format that the subroutine understands. If the subroutine opens the file and finds that the content is not correct, it can throw an exception to inform the caller of this fact. The caller can then intercept the exception with a try...catch or let it "flow" to the next caller in the stack, until one of the parent callers uses a try...catch to intercept the exception and perform an adequate action (such as reporting the error to the user).
    • Proposed as answer by Magnus (MM8)MVP Sunday, November 30, 2014 6:54 PM
    • Marked as answer by Barry Wang Monday, December 8, 2014 3:32 AM
    Sunday, November 30, 2014 5:43 PM
  • I would have thought this to be obvious. One codes a throw so that the routine immediately exists, and all local variables are freed. The exception may not be caught by the calling function; it might be called by some higher level function. In this case, all the local variables in the calling function are also freed, and the stack continues to be unwound until the exception is finally caught. From a programming point of view, one doesn't need to be concerned with variable clean up.
    • Marked as answer by Barry Wang Monday, December 8, 2014 3:32 AM
    Sunday, November 30, 2014 5:45 PM
  • Hi,

    In the old days, people used error codes to inform a method caller of success of failure in a subroutine. Exceptions are a more modern and much cleaner approach to error handling.

    The problem with returned error codes is that they not to be handle at the very point where the method returns. Exceptions do not have this flaw. They will be passed on up the call stack, until they find a matching catch block that handles the type of the exception. Or they end up as unhandled exceptions and the process crashes.

    Often is is a good idea to catch an exception deep down in the call stack in order to preserver some local state (write to log file) and then use

    throw;
    to throw the exception up to the next caller and (possibly) someone else to handle. 

    Rgds MM.

    • Marked as answer by Barry Wang Monday, December 8, 2014 3:32 AM
    Monday, December 1, 2014 1:35 AM

All replies

  • You throw an exception from a subroutine when you want to inform its caller that something unexpected went wrong. For example, you write a subroutine that imports a file into your database. The file is supposed to have a specific format that the subroutine understands. If the subroutine opens the file and finds that the content is not correct, it can throw an exception to inform the caller of this fact. The caller can then intercept the exception with a try...catch or let it "flow" to the next caller in the stack, until one of the parent callers uses a try...catch to intercept the exception and perform an adequate action (such as reporting the error to the user).
    • Proposed as answer by Magnus (MM8)MVP Sunday, November 30, 2014 6:54 PM
    • Marked as answer by Barry Wang Monday, December 8, 2014 3:32 AM
    Sunday, November 30, 2014 5:43 PM
  • I would have thought this to be obvious. One codes a throw so that the routine immediately exists, and all local variables are freed. The exception may not be caught by the calling function; it might be called by some higher level function. In this case, all the local variables in the calling function are also freed, and the stack continues to be unwound until the exception is finally caught. From a programming point of view, one doesn't need to be concerned with variable clean up.
    • Marked as answer by Barry Wang Monday, December 8, 2014 3:32 AM
    Sunday, November 30, 2014 5:45 PM
  • Hi,

    In the old days, people used error codes to inform a method caller of success of failure in a subroutine. Exceptions are a more modern and much cleaner approach to error handling.

    The problem with returned error codes is that they not to be handle at the very point where the method returns. Exceptions do not have this flaw. They will be passed on up the call stack, until they find a matching catch block that handles the type of the exception. Or they end up as unhandled exceptions and the process crashes.

    Often is is a good idea to catch an exception deep down in the call stack in order to preserver some local state (write to log file) and then use

    throw;
    to throw the exception up to the next caller and (possibly) someone else to handle. 

    Rgds MM.

    • Marked as answer by Barry Wang Monday, December 8, 2014 3:32 AM
    Monday, December 1, 2014 1:35 AM