Page Comparison

{float:side=right}{panel:title=Contents|borderStyle=solid|borderColor=black}{toc:minLevel=1|maxLevel=3}{panel}{float}

h2. Dealing with not instrumented paths


h3. Standard process



{float:side=right}
{code:title=Rethrowing exceptions}try {
    bar();   // method throws a MyException
} catch(MyException e) {
    // do some stuff
    throw e;
}
{code}
{float}

{float:side=right}
{code:title=Throw a new exception}
try {
    bar();   // method throws a MyException
} catch(MyException e) {
    // do some stuff
    throw new MyException();
}
{code}
{float}

The below picture shows the simplest case in a lifecycle of an Exception. The exception is created and thrown in an instrumented method (method read()), and afterwards handled at another position in the call tree (method create()). After catching the exception object, this object is not needed anymore and made eligible for the GC. But an exception can also be handled rethrown by reusing the exception object. This case is shown in the code snippet below. The lifecycle of the object doesn't end after the object was handled. The object is rethrown and the lifecycle continues until the next handler is found. An exception object can also be handled and rethrown by creating a new exception object of the same type. This case is shown in the code snippet below. The lifecycle of the handled exception is finished and a new exception lifecycle is started (by creating a new exception object).

 !exception_flow.png|width=419,height=375!

h3. Not instrumented paths

On the above examples all methods within a target application where instrumented. But with inspectIT we only want to instrumented specific parts (f.e. only methods that are within a specified starting point). Due to this fact, it is possible that events of throwing/handling an exception cannot be gained. The event of an exception object creation is always obtained, because all constructors of a Throwable class are instrumented at load-time (the event is also obtained when the exception object is created on a not instrumented path). The below description shows some possibilities, where not all events of an exception can be obtained.

!exception_flow_notInstrumented.png|thumbnail!

In the below picture the methods read() and getInput() can throw an exception of the same type. In this example an exception is created/thrown in the method getInput(), which is not instrumented. The exception object is then passed along the call stack and the JVM searches for a suitable handler. We are getting events of the creation and the handling of the exception object, but not the throwing. This is because the throwing event is on a not instrumented path (the object creation is also on a not instrumented path, but this event is gained due to the fact that all Throwable constructors are instrumented at load-time).

!exception_flow_handlerNotInstrumented.png|thumbnail!

It is also possible that an exception is created, thrown, and handled on a path which is not instrumented. This example is shown in the below picture. Due to not instrumented paths, we are getting only the creation event, but not the throwing/handling event.

!exception_flow_notInstrumentedPath.png|thumbnail!