How to Build a Java Method Call Stack Tracker for Faster Debugging

Current Situation Analysis

During on‑call duty, developers often receive error screenshots and must gather as much context as possible to diagnose the problem. A typical screenshot includes menu name, error message, and auxiliary data such as user‑entered codes, SKU, product name, and storage location.

Common troubleshooting steps are:

Verify the user‑provided code against the error message to confirm its existence and status.

If the code is a serial number and truly in the expected state, the issue can be closed after explanation.

If the code does not match the message, locate the source of the error text in the codebase and continue analysis.

Search the code repository or logs for the error text to pinpoint the originating method.

If multiple occurrences are found, further identify which one is relevant to the current incident.

These steps highlight the core challenge: quickly locating the code source from limited error information.

Insight from Exception Stack Traces

Java exception stack traces contain four essential pieces of information: fully‑qualified class name, method name, file name, and line number. The order of frames reflects the execution flow from the origin of the exception outward.

StackTraceElement represents a stack frame.

Every method invocation creates a stack frame that records this information, which can be leveraged even outside of exceptions.

Tool Development

The tool’s core code is straightforward: it iterates over StackTraceElement arrays, filters out unwanted entries, and formats the remaining frames into a readable chain.

Key parameters:

pretty : include only class and method names (omit file name and line number).

simple : filter out proxy‑generated methods.

specifiedPrefix : retain only frames whose package prefixes match a whitelist.

Additional filters remove common proxy artifacts such as FastClassBySpringCGLIB, EnhancerBySpringCGLIB, lambda$, Aspect, and Interceptor.

Example of a filtered call stack (no middleware or proxy methods):

Thread#run ==> ThreadPoolExecutor$Worker#run ==> ThreadPoolExecutor#runWorker ==> BaseTask#run ==> JSFTask#doRun ==> ProviderProxyInvoker#invoke ==> FilterChain#invoke ==> SystemTimeCheckFilter#invoke ==> ProviderExceptionFilter#invoke ==> ProviderContextFilter#invoke ==> InstMethodsInter#intercept ==> ProviderContextFilter$eone$auxiliary$9f9kd21#call ==> ProviderContextFilter#eone$original$invoke$p882ot3$accessor$eone$pclcbe2 ==> ProviderContextFilter#eone$original$invoke$p882ot3 ==> ProviderGenericFilter#invoke ==> ProviderUnitValidationFilter#invoke ==> ProviderHttpGWFilter#invoke ==> ProviderInvokeLimitFilter#invoke ==> ProviderMethodCheckFilter#invoke ==> ProviderTimeoutFilter#invoke ==> ValidationFilter#invoke ==> ProviderConcurrentsFilter#invoke ==> ProviderSecurityFilter#invoke ==> WmsRpcExceptionFilter#invoke ==> AdmissionControlJsfFilter#invoke ==> ChainedDeadlineJsfFilter#invoke ==> JsfPerformanceMonitor#invoke ==> ProviderInvokeFilter#invoke ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1704#invoke

Further examples demonstrate filtering by package prefix and retaining file names and line numbers when needed.

Online Application Practice

After integrating the call‑stack tracing tool, developers can search logs using error keywords to quickly locate the entry point. For instance, tracing from ImmediateTransferController#offShelf leads to the exact business method handling the request.

Applicable Scenarios

Output stack traces to logs during business exceptions.

Include call‑stack information in monitoring alerts.

Display call chains in complex method‑reuse situations for easier analysis.

Other custom scenarios where stack information aids troubleshooting.

Extension

For further reading, see the related article "How to Pinpoint SQL Code Origin with a Simple MyBatis Plugin" which integrates the call‑stack tool to enrich SQL tracing.