Getting Started

Please, follow this introductory guide to get a first look at the project.

  1. Introduction to Exceptions
  2. Blunder basic Elements
  3. Knowledge base structure
  4. Algorithm for solving error Contexts
  5. Auto learning mode

1. Intoduction to Exceptions [^]

First of all, ensure you are familiar with the concept of Java Exceptions and Chained Exceptions. You can learn it from the Sun's official pages:

So, now you've refreshed all those concepts lets move on!

2. Blunder basic Elements [^]

Blunder analizes the chained exception and extracts from it three main elements:

  • Root: the original Exception -first on the chain-.
  • Leaf: the last caused Exception.
  • Business: a Exception in the middle chain the first from your bussiness packages.

At least two of these elements could form a context that can be identified and typified. The element Business is optional due to the chain doesn't have always an Exception from your own packages. Instead of it, the element Root and Leaf could be the same Exception object -only one link chains-.

Elements in the Chained Exception
Figure 1: Elements in the Chained Exception.

3. Knowledge base structure [^]

To gain the flexibility to adapt to different situations, we had to define a data model that supports the different possible cases. It therefore defines the following attributes that relate to chained exceptions.

  • CONTEXT_ID: id of the error context. By convension, 0 is the default context. This is a unique identifier of all contexts.
  • LEAF_CLASSNAME: qualified name of top first Exception on the chain.
  • ROOT_CLASSNAME: qualified name of the bottom Exception on the chain. The first exception that occurs in the system.
  • BUSINESS_CLASSNAME: qualified name of the first business Exception on the chain (bottom-up).
  • CONDITIONS: dynamic language expression evaluated over the context with a boolean result (true or false). It's used in the case you wish to discriminate between two similar chained exceptions. Currently, the language used is OGNL (*).
  • FAULT_CATEGORY: category of the error context. Could be Business, Client, Server, User or others. It's used to determine the responsibility of the exception.
  • FAULT_STRING: dynamic language expression used to create the error message to show to the user. It's an OGNL (*) expression and can be build with properties from any of the Exceptions.
  • POSSIBLE_SOLUTIONS_LIST: an OGNL (*) array with a list of possible solutions for the current error context. Like a check list for not to fail again the next time the user tries to re-execute the failed process.
  • MATCH_AT_RUNTIME: boolean attribute. Determines whether a context is or not available at runtime. When yoe are running in auto learning mode if the context exists but it's not available for runtime, Blunder doesn't tries to learn it.
  • DEBUG_STACK_TRACE: in auto learning mode, when a chained exception is ready to be learned, we also learn it's stack trace. It's just for having a detailed information about when it happened.

(*) We are working on an implementation for multiple dynamic languages support. We hope to be available as soon as possible.

These attributes are what Blunder used to represent the different error situations, to distinguish between them and resolve accordingly.

The knowledge base, could be persisted in a database table, csv file or a Java binary file. Please take a look at the supported media persistence section.

4. Algorithm for solving error contexts [^]

Once found the basic components of a chained exception, the search in the knowledge base is done through the following algorithm. At each step, if it doesn't find any results that match the current context error, continue with the next step.

  1. Tries to find a context with the three main elements, Leaf, Root and Business.
  2. If no match is found or doesn't meet the conditions, then try to find a context with the components, Leaf and Root.
  3. Then, it tries to find a context with the components Leaf and Business.
  4. Then tries to find a context with the compoent Leaf.
  5. Then tries to find a context with the compoent Root.
  6. And finally if none of those steps could solve the context, then it resolves with the default context. It is the one with the ID 0 (zero).

Always is verified the expression in CONDITIONS and the availability of the context in runtime (MATCH_AT_RUNTIME='true').

The main idea behind this series of steps is the generalization. Start with a search as specific as possible and go generalizing step by step. For example it is not necessary that all fields match the current situation; so we could take as rule that every chained exception that was originally generated by a is a comunication problem, therefore we would like to address as a server error and suggest to the user to retry again in a few minutes. For this, we should specify a context with only this exception as root(id=3 in the table) and all others learned contexts with as Root should be marked as MATCH_AT_RUNTIME='false' (id=1 and id=2 in the table). The following table illustrates this situation.

Id Leaf Business Root Conditions Match_at_runtime
1 com.myapp.BusinessLogicException com.myapp.MyAppException true false
2 com.myapp.UserInputException - true false
3 - - true true

In future releases of Blunder, we are planning to make this algorithm customizable.

5. Auto learning mode [^]

Blunder has an Auto-learning mode wich can be used to learn the new contexts from the application errors. The idea is to provide a starting point for the developer and functional analyst to verify and establish the general attributes of the learned error.

The auto-learning mode is enabled through the Java system property blunder.autolearning=true. When this property is enabled, Blunder tries to learn the error contexts that aren't in the knowledge base but just in the steps 1 and 2 from the previuos list. To determine whether or not to learn a new context, in addition to checking each of the basic components, play a very important part the result of evaluating the attribute CONDITIONS; because it can detected a Chained Exception with identical components but responding to different conditions of the context. The next table tries to exemplify the cases where it is and where not learned the new context.

In Knowledge base Conditions Match at runtime Should learn?
Yes True Yes/No No
Yes False Yes/No Yes
No - - Yes

This feature is of great help at the moment of detect and classify different error contexts. However, there is always at the discretion of the person responsible for carrying out the project, filter, categorize and placing an appropriate message to each of the cases learned. These attributes depend on a thorough and detailed analysis on the data collected.

The use of auto-learning, must be monitored and supervised, is not recommended to enable it to work on iterations in development as it could detect and learn many errors that arise during the programming of an application and not a final version.