Identifying Your Code vs Framework Code in a Stack Trace

Direct Answer

In a stack trace, your code's at lines start with your project's package (e.g. com.myapp...), while framework lines start with org.springframework, java., jakarta., org.hibernate, etc. The bug is almost always in your lines, so scan the trace and focus on the topmost frame in your own package — the framework frames above it are just the plumbing that called you.

Deep Dive & Architecture

A frame's fully qualified class name shows its package. Application frames may begin with com.example.orders, while Java and framework frames may begin with java., jdk., org.springframework, or another dependency package.

Start from the relevant throwable or cause and locate the nearest frame in code the team owns. For example, OrderService.place(OrderService.java:42) below MVC frames is a useful inspection point because it connects the failure to application behavior.

Package ownership does not decide fault. Application code can pass an invalid value into a correct framework, configuration can make a framework fail, and a library can contain a bug. Combine frames with the exception message, cause chain, versions, and runtime inputs.

Code Example

java.lang.IllegalArgumentException: id must be positive
    at java.base/java.util.Objects.checkIndex(...)         <- JDK (skip)
    at org.springframework.web...invokeHandlerMethod(...)  <- framework (skip)
    at com.myapp.order.OrderService.find(OrderService.java:31)  <- YOUR code: START HERE
    at com.myapp.order.OrderController.get(OrderController.java:18) <- your caller
    at org.springframework.web...doDispatch(...)           <- framework (skip)

The two com.myapp lines are yours; everything else is the framework calling into (and out of) your handler.

Common Mistakes & Pitfalls

• Blaming the framework name at the top without checking the caller and input.
• Blaming application code automatically when a dependency or runtime version may be faulty.
• Ignoring the cause chain and examining an unrelated outer frame.
• Using a package rule only instead of reading messages and configuration.
• Opening a different source revision from the deployed build.