Application Real-Time Monitoring Service:Exception analysis

Both methods catch exceptions

public int methodA() {
    try {
        return methodB();
    } catch (Throwable e) {
        e.printStackTrace();
        return 0;
    }
}

public int methodB() {
    try {
        return 1 / 0;
    } catch (Throwable e) {
        e.printStackTrace();
        return 0;
    }
}

Result: ARMS records no exceptions. Both exceptions are caught and handled within their respective try-catch blocks.

Only one method catches the exception

public int methodA() {
    try {
        return methodB();
    } catch (Throwable e) {
        e.printStackTrace();
        return 0;
    }
}

public int methodB() {
    return 1 / 0;
}

Result: ARMS records one java.lang.ArithmeticException -- uncaught in methodB.

Neither method catches the exception

public int methodA() {
    return methodB();
}

public int methodB() {
    return 1 / 0;
}

Result: ARMS records two java.lang.ArithmeticException exceptions -- one for each instrumented method where the exception propagates uncaught.

Catch and rethrow as a different exception type

public static int methodA() {
    try {
        return methodB();
    } catch (Throwable e) {
        throw new RuntimeException(e);
    }
}

public static int methodB() {
    return 1 / 0;
}

Result: ARMS records two exceptions:

• One java.lang.ArithmeticException -- uncaught in methodB

• One java.lang.RuntimeException -- thrown by methodA

Exception count for an API exceeds request count

This can occur for the following reasons:

• ARMS records an exception when it is thrown by an instrumented method. If multiple instrumented methods throw exceptions during a single API call, ARMS records multiple exceptions for that call.

• If the same exception propagates up the method stack through multiple instrumented methods, ARMS records the exception multiple times.

Exception data changes after agent upgrade

Each agent version may change the set of instrumented methods. When the number of instrumented methods increases or decreases, the number of captured exceptions changes accordingly.

ARMS shows exceptions not caught by business logic

In many framework libraries instrumented by the agent, some exceptions are caught and handled internally at the framework level and are not thrown to your business code. The agent captures these exceptions, but your application is unaware of them.

For example, a call to access MongoDB by using MongoTemplate may not report an exception in your application, but you might see exceptions in the ARMS console. This is because MongoTemplate contains built-in retry logic. When a timeout occurs, MongoTemplate retries the operation and throws an exception to the caller only after multiple retries fail. Therefore, if you use MongoTemplate to access MongoDB and an underlying timeout and retry occurs, your business logic might not see an exception, but you can see exceptions in the ARMS console.

Mismatched exception stack traces

To improve data processing and reporting efficiency, the ARMS agent generates a fingerprint for each exception based on its class name, the first three lines of the method stack, and the last three lines of the method stack. This fingerprint is then encoded into a 64-bit value by using CRC64. The first time an exception occurs, the agent reports both the encoded value and the original value. For subsequent identical exceptions, only the encoded value is reported. This can cause the displayed stack trace to mismatch the actual stack trace in two situations:

• Two exceptions have different full method stacks but share the same class name and the same first three and last three lines of their method stacks. This processing logic results in an identical encoded value, which causes a mismatch.

• Two exceptions have different class names or different first three or last three lines of their method stacks, but their encoded values are the same. This can happen due to hash collisions from the non-unique CRC64 encoding algorithm.

If either of these situations occurs, you can increase the value of the similar exception stack differentiation depth parameter in the Exception Advanced Filtering Configuration section of the Custom Configurations page.

Exceptions displayed as IDs after 30 days

To optimize the amount of reported data, ARMS encodes an exception and reports both the encoded value and the original value to the server when the exception first occurs. The server stores this mapping, which expires after 30 days. If an application runs for more than 30 days, the server may no longer be able to look up the original exception value from the encoded value.

Exceptions not displayed in the console

By default, the ARMS agent collects exceptions only from methods that it instruments.

If you use agent version 4.1.12 or later, you can go to the Custom Configurations page and enable the exception plugin in the agent switch settings section. After you enable the plugin, ARMS collects data every time an exception instance is created.