When applications throw uncaught exceptions in production, identifying which errors matter and where they originate is difficult without centralized tracking. Application Real-Time Monitoring Service (ARMS) automatically captures every uncaught Java exception -- those that propagate outside try-catch blocks -- regardless of how often they occur, or whether they are thrown by code or returned by runtime failures, and aggregates them by type. This gives you a single view of all unhandled errors across your application.
Prerequisites
Before you begin, ensure that you have:
An application monitored by Application Monitoring
View exception analysis
Log on to the ARMS console. In the left-side navigation pane, choose Application Monitoring > Application List.
Select a region in the top navigation bar and click the target application.
Icons in the Language column indicate the programming language: -
: Java - 
: Go - 
: Python - - (hyphen): an application monitored in Managed Service for OpenTelemetryIn the left-side navigation pane, click Application Details.
Select an instance, set the time range in the upper-right corner, and click the Exception Analysis tab.
Exception chart
The Exceptions section displays a stacked chart of all exceptions during the selected time range. Each layer represents a distinct exception type, making it easy to spot which errors dominate and when spikes occur.
Interact with the chart:
| Action | Result |
|---|---|
| Hover over the chart | View statistics at a specific point in time |
| Drag horizontally | Zoom into a narrower time range |
Click the  icon | Compare metrics across time periods or across different days within the same time window |
Click the  icon | View the API details of the metric |
Exception list
Below the chart, the exception list shows every exception type that occurred during the selected time range. Use the Actions column to drill down into individual exceptions:
| Action | Description |
|---|---|
| Invocation Statistics | View a stacked chart for the selected exception, showing its occurrence pattern over time. |
| Interface Snapshot | View traces associated with the exception to identify the affected operations and their call chains. |
| Details | View the full exception details. |
Filter exceptions
To filter exceptions, specify the Whitelist field in the Advanced Settings section:
Open the Application Settings page and click the Custom Configuration tab.
In the Advanced Settings section, specify the exception classes in the Whitelist field.
How exception recording works
ARMS records an exception each time it escapes a try-catch block in an instrumented method. Exceptions caught and handled within a try-catch block are not recorded.
The following scenarios demonstrate this behavior. Assume the ARMS agent has instrumented both methodA and methodB:
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 inmethodBOne
java.lang.RuntimeException-- thrown bymethodA