How the JVM tells you where things actually broke
An exception thrown three methods deep does not stay there. This session follows it up the call stack, teaches you to read the trace the JVM prints, and then has you write an exception of your own.
This session has not been authored yet
You have reached a real page, but an empty one. The deck for Class 19 is planned in full in the course knowledge document and is queued for authoring — nothing on this page is finished teaching content.
The roster underneath is the actual plan for this session, so you can see exactly what will land here.
What this class will cover
- Class-19 openerThe hook: how the JVM tells you where things actually broke.
- Exception propagationHow an exception travels up the call stack — and what happens when nobody catches it.
- Reading a stack traceWhat every single line of that wall of text actually means.
- Worked example · a real crash logA genuine crash from the food-ordering app's cart, read line by line until the real bug is found.
- User-defined exceptionsExtending
ExceptionorRuntimeException— when, and how. - Checked or unchecked for your own?The design decision behind which base class to pick, and what it forces on your callers.
- OutOfStockExceptionThe food-ordering cart throws it when stock hits zero — full class, the throw site, and the catch in the caller.
- Activity 1 · trace the propagationA three-level call stack, with the exception thrown in the deepest method.
- Activity 2 · design WeakPasswordExceptionA custom exception for a signup form — the class skeleton and one throw site.
- Activity 3 · reflectionThe strangest exception message you have hit so far, and what it turned out to mean. Then the Class-19 close card.
The skill that outlasts the exam
Reading a stack trace properly is the single most transferable thing in this unit. Every language prints one, every job interview assumes you can read one, and it is the difference between "it broke" and "line 41 of Cart.java handed a null to getPrice()".