Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. Efficient Exception Bubbling

Efficient Exception Bubbling

Scheduled Pinned Locked Moved Design and Architecture
debuggingquestion
3 Posts 2 Posters 9 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    T Offline
    Tristan Rhodes
    wrote on last edited by
    #1

    Guys There are regular situations in the code base i am working on where exceptions are thrown but nothing is done with them. The end result is vague exceptions being caught at the top level with no information regarding what went wrong. As a result, i have begun catching them, adding data relevant to the location where they were caught, and re-throwing. In some cases the same exception can be caught and re-thrown 4+ times. I know exceptions are slow, but what are the other options? Note: Generaly these exceptions shouldn't be thrown that often and are a vital debug tool Regards Tris

    P 1 Reply Last reply
    0
    • T Tristan Rhodes

      Guys There are regular situations in the code base i am working on where exceptions are thrown but nothing is done with them. The end result is vague exceptions being caught at the top level with no information regarding what went wrong. As a result, i have begun catching them, adding data relevant to the location where they were caught, and re-throwing. In some cases the same exception can be caught and re-thrown 4+ times. I know exceptions are slow, but what are the other options? Note: Generaly these exceptions shouldn't be thrown that often and are a vital debug tool Regards Tris

      P Offline
      P Offline
      Pete OHanlon
      wrote on last edited by
      #2

      Tristan I think you have to ask yourself why you are rethrowing an exception so many times. Exceptions serve the purpose of allowing you to deal with a problem as soon as possible. The further up the trace strack you go, the lower the value of the exception becomes. For instance, suppose that I'm trying to open a file. If the file isn't present, I should expect to receive a FileNotFound exception. Now, this shouldn't bubble back up the chain because there is less that I can do with it at each stage back up the stack. What I should do is handle it at the point that the exception was first caught. Now, why are you catching exceptions? Generally this is because you either want to be able to handle extraordinary conditions gracefully, e.g. don't attempt to read the file in if you receive a FileNotFound exception, or because you want to capture the fact that your code failed. In the first case, you want to handle the exception and move on. In the second case, you want to identify what happened where. Throwing it back up the chain isn't going to help you one bit in the second case. What you should really look at is implementing some form of logging mechanism and use that to log exceptions. Finally - only rethrow an exception if there is value in doing it, e.g. by breaking the normal program flow to cater for exceptions.

      Deja View - the feeling that you've seen this post before.

      T 1 Reply Last reply
      0
      • P Pete OHanlon

        Tristan I think you have to ask yourself why you are rethrowing an exception so many times. Exceptions serve the purpose of allowing you to deal with a problem as soon as possible. The further up the trace strack you go, the lower the value of the exception becomes. For instance, suppose that I'm trying to open a file. If the file isn't present, I should expect to receive a FileNotFound exception. Now, this shouldn't bubble back up the chain because there is less that I can do with it at each stage back up the stack. What I should do is handle it at the point that the exception was first caught. Now, why are you catching exceptions? Generally this is because you either want to be able to handle extraordinary conditions gracefully, e.g. don't attempt to read the file in if you receive a FileNotFound exception, or because you want to capture the fact that your code failed. In the first case, you want to handle the exception and move on. In the second case, you want to identify what happened where. Throwing it back up the chain isn't going to help you one bit in the second case. What you should really look at is implementing some form of logging mechanism and use that to log exceptions. Finally - only rethrow an exception if there is value in doing it, e.g. by breaking the normal program flow to cater for exceptions.

        Deja View - the feeling that you've seen this post before.

        T Offline
        T Offline
        Tristan Rhodes
        wrote on last edited by
        #3

        Excelent, thanks. Food for thought. It was option 2 actualy, but there are an excessive quantity of Try / Catch blocks in existance which do nothing. I'm actualy trying to bring order to chaos and have a good clean up of an existing code base that throws meaningless errors. :( Cheers Tris

        ------------------------------- Eats: Software Sleeps: Software Drinks: Decaf

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups