Code Exceptions Test

In Java “an event that occurs during the execution of a program that disrupts the normal flow of instructions” is called an exception. This is generally an unexpected or unwanted event which can occur either at compile-time or run-time in application code. Java application developers often struggle to detect and manage the 'run-time' exceptions, as its difficult to predict when they will occur. Most commonly, such exceptions may occur when specific transactions are performed on the target Java application. If such transactions are not promptly captured, then application developers may not be able to determine where in the application code the corresponding exceptions need to be handled or how to handle them. As a result, the transactions will continue to throw the Java exceptions, thereby impacting user experience with the target application. To avoid this, it is important to quickly identify which transactions throw Java exceptions. This is where the Code Exceptions test helps!

This test automatically groups business transactions to a target application based on run-time Java exceptions that eG BTM detects in them. For each such exception-based transaction group, the test then reports the count of transactions in which those exceptions were observed. In the process, the test sheds light on those Java exceptions that have affected the maximum number of transactions. The detailed diagnosis of the test (if enabled) reveals which transactions were affected by which Java exceptions.

Target of the Test : A BTM-enabled JVM

Agent deploying the test : An internal/remote agent

Output of the test : One set of results is reported for each type of Java exception captured in business transactions. For the Summary descriptor, metrics are aggregated across all Java exceptions.

Test parameters:

Configurable parameters for the test

Parameter	Description
Test Period	How often should the test be executed.
Host	The host for which this test is to be configured.
Port	Specify the port at which the specified Host listens
Enable Rootcause Exception Tracking	Sometimes, a Java exception may ripple and trigger one/more other exceptions. In other words, some exceptions may occur as a chain reaction to another exception. In such cases, this test, by default, will not perform end-to-end exception tracing - i.e., it will not trace the complete path of an exception till the root exception that caused it is identified. Instead, the test will only trace down one level to discover and report the immediate parent of the exception in question. For instance, take the case of the 'exception chain' below: java.lang.RuntimeException: Error in level1 at ExceptionChainExample.level1(ExceptionChainExample.java:15) at ExceptionChainExample.main(ExceptionChainExample.java:6) Caused by: java.lang.IllegalStateException: Error in level2 at ExceptionChainExample.level2(ExceptionChainExample.java:23) at ExceptionChainExample.level1(ExceptionChainExample.java:13) Caused by: java.lang.IllegalArgumentException: Root cause error at ExceptionChainExample.level3(ExceptionChainExample.java:29) at ExceptionChainExample.level2(ExceptionChainExample.java:21) In the case above, it is clear that the java.lang.RuntimeException, is caused by the java.lang.IllegalStateException, which in turn is caused by the java.lang.IllegalArgumentException. In short, the java.lang.IllegalArgumentException is the root-cause of the java.lang.RuntimeException. By default however, this test will only capture and report the java.lang.RuntimeException and its immediate cause, which is the java.lang.IllegalStateException. This is because, the Enable Rootcause Exception Tracking flag is set to No by default. On the other hand, if you want the test to take you closer to the root cause - i.e., capture the java.lang.IllegalArgumentException as well in the example above - then, set the Enable Rootcause Exception Tracking flag to Yes.
Mask Exception Message	Exception messages can sometimes include variables that carry sensitive information in plain text. If users with malicious intent come in contact with such information, it can prove to be a serious threat to the security of your mission-critical apps. To prevent the misuse of such confidential information, eG Enterprise, by default, uses the * (asterisk) character to mask the variables in all exception messages. This is why, the Mask Exception Message flag is set to Yes by default. If you want, you can unmask these variables by setting the same flag to No.
Ignore Exceptions	By default, this test captures and reports all Java exceptions that the target application throws - both handled exceptions and unhandled ones. Sometimes however, administrators may want eG to disregard certain unhandled exceptions (or handled SQL exceptions), as they may not pose any threat to the stability of the transaction or to the web site/web application. To achieve this, administrators can configure a comma-separated list of such inconsequential exceptions in the Ignore Exceptions text box. Here, you need to configure each exception you want to exclude using its fully qualified exception class name. For instance, your excluded exceptions specification can be as follows: java.sql.SQLException, java.io.FileNotFoundException. Note that wild card characters cannot be used as part of your specification. Once the exceptions to be excluded are configured, then this test will disregard all those transactions in which such exceptions are captured.
DD Frequency	Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measures reported by the test

Measurement	Description	Measurement Unit	Interpretation
Exceptions	Indicates the number of transactions that encountered this Java exception during the last measurement period. For the Summary descriptor, this indicates the total number of transactions that encountered Java exceptions during the last measurement period, regardless of the exception type.	Number	Compare the value of this measure across Java exceptions to identify the exception that has affected the performance of the maximum number of transactions. Use the detailed diagnosis of this measure to know which transactions were affected by Java exceptions of this type.
Exceptions per minute	Indicates the number of transactions that encountered this Java exception per minute. For the Summary descriptor, this measure will report the total number of transactions per minute that threw Java exceptions, regardless of the exception type.	Number	Compare the value of this measure across Java exceptions to determine which type of exception was frequently encountered by the target application.
Unique exceptions	Indicates how many distinct types of exceptions occurred during the last measurement period.	Number	This measure is reported only for the Summary descriptor.
Exception percentage	Indicates the percentage of transactions that encountered this Java exception during the last measurement period. For the Summary descriptor, this measure will report the percentage of total transactions that encountered Java exceptions, regardless of the exception type.	Number	Compare the value of this measure across Java exceptions to determine which type of exception affected a majority of the transactions.

Note:

By default, the detailed diagnosis of this test only reveals which business transactions were affected by a specific type of Java exception. However, it does not reveal what is the cause of that exception. To obtain useful root-cause analytics from the detailed diagnosis of this test, edit the btmOthers.props file available on the eG BTM-enabled JVM, and toggle the following flags in it:

• CAPTURE_CAUSE_OF_EXCEPTION: By default, this flag is disabled. Set this flag to true, if you want the detailed diagnosis of the test to reveal the Java exception that is the immediate cause of the exception in question. In other words, if the Java exception in question occurred soon after and as a result of another exception in the same transaction, then setting this flag to true will display that parent transaction in the detailed diagnosis.

• ENABLE ROOT CAUSE EXCEPTION TRACKINGand MAX_EXCEPTION_CAUSE_DEPTH: A single Java exception in a transaction may sometimes trigger one or more child exceptions in the same transaction. In such situations, knowing which Java exception is the 'source' of all child exceptions, including the exception in question, will help application developers figure out how to handle that exception in code. In such cases, the exception captured at source is treated as the 'parent' of all the child exceptions it spawns, and is hence deemed to be the root-cause of the exceptions. By default, the ENABLE ROOT CAUSE EXCEPTION TRACKING flag is set to false, indicating that by default, the detailed diagnosis of this test does not reveal the 'root-cause' of the Java exception. If this flag is set to true, then detailed diagnosis will enable you to trace down a transaction stack to hierarchically view a specific number of parent Java exceptions that had occurred in that transaction, before the monitored exception occurred. By default, this specific number is 10. Accordingly, the MAX_EXCEPTION_CAUSE_DEPTH parameter is set to 10 by default. You can increase the value of this parameter, so you can view more parent Java exceptions in the detailed diagnosis and perform root-cause analytics effectively. For instance, if this value is set to 20, then the detailed diagnosis of the test will trace back from the exception in question to display 20 parent Java exceptions that occurred before it.