error-debugging

Purpose

Turn an error message into an explanation and a fix. The input is whatever the user has — a stack trace, a crash report, a panic, a log excerpt, sometimes just a screenshot description. The output is: which line actually failed, why it failed, what to change, and how to confirm the change worked.

Most of the value is in the middle step. The frame that throws is rarely the frame that is wrong — a NullPointerException in a rendering routine usually means something upstream handed it a null it never should have had. Report the cause, not the symptom.

When to use

• The user pastes a stack trace, crash report, panic, ANR, or error log — with or without a question
• The user asks what an error means, why an app crashes, or where a failure comes from
• A release-build trace needs deobfuscation or symbolication before it can be read
• A test failure, build failure, or runtime log needs root-causing