Posts Tagged ‘programming’

Thinking About Exceptions

April 5, 2010 Leave a comment

Application and operational architects should consider what can wrong in applications whether or not the scenario is officially documented as a non-functional requirement or in a use story. While you must be practical because there are always trade offs between bullet proofing and delivery time frames, lack of requirements should never be an excuse to deliver software with poor operational supportability.

 The table below includes sample exception situations that could occur in an application and suggestions for system responses. The goal of this list is to help you identify potential problems that could occur in your code and so that they can be appropriately addressed.

A resource call does not return within a reasonable period of time (applicable to synchronous events but should also be considered for long running BPM processes)Examples:
A call to a persistence layer takes longer than it must.
* Session bean call does not return within a reasonable period of time.
Treat as a timeout
* Give user the option of interrupting the call
*The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
A resource request times out.
* DB query times out
* A Web service request times out.
The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
Resource conflict, in which two or more users attempt to access a resource in a manner that causes one or both requests to fail (not time out).
* An attempt by a user to perform an update using data is stale, causing the application to detect that the user update is in conflict with an earlier update (i.e., the “optimistic locking” paradigm).
* Attempts by two users to perform operations that are only allowed to be performed by one user at a time, based on application rules.
The exception that is thrown must indicate which data is affected by the conflict.
* The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
Data not yet available, due to delays.
* A precursor process has not yet completed.
The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
Server-based resource runs out of a type of resource that it requires.
* Database table space (especially temporary tables).
* memory
Technical support must be notified automatically. Can be handled via logging level.
* To the extent possible, no database data must become corrupt or inconsistent as a result of the failure.
* The exception that is returned to the caller must specify the specific condition (for example, which server resource could not be connected to) and the completion status of any transactions that were in progress on the caller’s behalf, and any inconsistencies that might have resulted.
* Any exception that is logged must include the full context of the error, including the stack trace, the user identity, and a request or task identity for the purpose of correlating log events across different environments.
* A GUI-level client must instruct the user to wait until a message is received indicating that the resource is available again.
* When the system becomes usable again, users must receive a message instructing them with what operations they must re-perform.
An attempt to establish a connection to or otherwise obtain a resource fails.
* An attempt to establish a database connection fails.
* A utility such as a task management system, a queuing system, or a file transport system is unavailable.
Same as previous.
A resource connection fails unexpectedly.
* A remote machine is being rebooted or was shut down.
Same as previous.
An attempt to locate (resolve) a resource fails Examples:
* A database table is not found because it is not in the user’s schema.
Same as previous.
There is a version mismatch between two ends of a remote connection or session.
* An XML message or Web Service invocation fails a schema or DTD validation (at either endpoint).
Same as above.
There is a protocol usage or internal error of some kind that is not immediately identifiable as a version incompatibility.
* A semantic error within a Web Service message, such that the message is ill-formed based on usage rules that are not encoded in the schema, or no schema is being used.
Same as previous.
An internal error in a server-based application occurs when making a remote call to the application.
* A Web Service throws a RuntimeException or Error.
Same as previous.
An attempt to authenticate to a resource or to obtain authorization to access the resource fails.
* An attempt to update a database table fails with an authorization exception.
* An attempt to access a file fails due to lack of the required access permission.
All exception information must be logged in a secure manner, and the exception must then be replaced with a generic exception indicating an authentication or authorization failure, as appropriate.
Input validation error. Any exception that is returned to the caller must indicate the specific input items that were problematic. If the caller is a user interface, the specific problematic items must be visually indicated.
* The intended transaction must not occur.