Reusable Exception Handling for Services – Podcast Episode

November 13, 2010
Want to listen using iTunes?

Using iTunes?

podcast

New episode added to the Software Reuse Podcast Series on designing reusable exception handling for SOA efforts. It elaborates on using a simple set of components for handling exceptions, capturing relevant metadata, and determining notifications.

Like this post? Subscribe to RSS feed or get blog updates via email.

Advertisements

List of Return Codes for SOA

November 18, 2009

List of Return Codes

I wrote earlier about the idea of using consistent error codes for reusable assets. As a follow up, here is a document with a list of reusable return codes that can be used when building service capabilities as part of SOA initiatives. They are categorized into:

  • request processing
  • data processing
  • dependency access
  • transactions

This isn’t an exhaustive list by any means but can get you started in terms of achieving consistency across services and projects.The service consumer can use the return code to understand the service provider’s response. This consistent, uniform categorization of return codes can help you reuse error handlers (e.g. handle a particular error in the same way regardless of which service capability raised it).  It will also help with production support and troubleshooting – less learning curve for support staff and developers to categorize errors at runtime.

Note: The return code derived based on errors need not necessarily be the return code sent back to the service consumer. It is entirely possible that you return a friendly error to the consumer and a detailed error to production support.

Are there additional ones to include in this list?

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook


Software Reuse Quick Tip #17

August 25, 2009

Tip #17 – Return informative and actionable exceptions from reusable assets

Reusable assets such as service capabilities need to return both technical and business (or domain relevant) exceptions. If a service or component returns a business exception often times it is useful to provide additional information to resolve the exception as well. Similarly, if a business exception needs a human user to resolve (e.g. fixing incorrect data, overriding a business rule, escalating to a manager based on business rules) you will want to return this information. It signals to the consumer that repeatedly invoking the call won’t resolve the problem.

Exceptions must follow a standard format that provides information for two audiences – internal support team and your external consumer. They should include warnings, statuses, remedial steps, retry procedure in addition to the core exception (if applicable). From a reusable asset standpoint, consistent exceptions signal robustness. It is critical for your consumers to know that the asset returns high quality exceptions and handles them gracefully. For your internal support staff, you should add additional diagnostic information such as stack trace, location of exception, state of key variables, as well as possible resolutions to the problem. For reusable services, this could make the difference between successfully recovering due to a failure and missing a key consumer’s SLA requirements. In other words, your exceptions need to be as informative and actionable as possible.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: