Self-Reflection on Exception-Handling

I spent this week on refactoring my code of past three months. It’s a torturous work. And the one which makes me want to tear my hair out, is Exception-Handing. I luckily followed almost all the Not-To-Do listed in <Exception-Handling Antipatterns> .

Actually Exception-Handling design have great influence on total quality.Bad Exception-Handling sometime ruin good design. I list here some guideline mentioned in <Toward Exception-Handling Best Practices and Patterns> .Make it right even if it goes wrong.

  • Don’t try to handle coding errors.
  • Avoid declaring lots of exception classes.
  • Name an exception after what went wrong, not who raised it.
  • Recast lower-level exceptions to higher-level ones whenever you raise an abstraction level.
  • Provide context along with an exception.
  • Handle exceptions as close to the problem as you can.
  • Assign exception-handling responsibilities to objects that can make decisions.
  • Use exceptions only to signal emergencies.
  • Don’t repeatedly rethrow the same exception.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s