Reading errors without fear

The skill nobody tells you about

Here is something that would have saved most beginners a lot of misery if someone had said it on day one:

Professional developers see errors constantly. Dozens a day. Red text is not an exam result and it is not a verdict on you. It is the normal texture of the work — the machine noticing something before it becomes a problem, and telling you where.

The difference between someone who finds coding fun and someone who finds it crushing is almost never talent. It is whether they read the error or panic at the sight of it.

By the end of this lesson you will be able to look at any red block and answer three questions in about ten seconds: which kind of error is this, which file, which line. That is the whole skill. Everything after it is just fixing.

Three kinds of error, in the order you meet them

You will meet them in a fixed sequence, and knowing which one you are looking at tells you where to go next.

The distinction between 2 and 3 is the important one, and it is worth being precise about.

A build error means your code could not be turned into an app. Nothing was installed; whatever is on your phone is still the previous version. The compiler caught it.

A runtime error means your code built perfectly, installed perfectly, ran, and then hit a situation it had no answer for — dividing by zero, asking for the fourth item of a three-item list. The compiler could not have known, because it depends on what actually happens.

Build errors are the friendly kind. You want as many of your mistakes as possible to be build errors, which is a large part of why Kotlin is designed the way it is.

Anatomy 1 — a Kotlin error line

This is the format you will see most often. Every part of it is doing a job.

1e: MainActivity.kt:24:19 Unresolved reference 'nam'.
2^  ^               ^  ^  ^
3|  |               |  |  └ what is wrong
4|  |               |  └ column 19
5|  |               └ line 24
6|  └ which file
7└ e: = error   (w: = warning)

Read it right to left and it becomes a sentence: there is a word here nobody has defined; it is called nam; it is 19 characters along line 24 of MainActivity.kt.

The column number is the part most people ignore, and it is the most useful part on a phone. Line 24 might be long. Column 19 is a single word.

Anatomy 2 — a Gradle failure block

When the build fails, the last thing on screen is not your error. It is this:

1FAILURE: Build failed with an exception.
2
3* What went wrong:
4Execution failed for task ':app:compileDebugKotlin'.
5> A failure occurred while executing
6  org.jetbrains.kotlin.compilerRunner.GradleCompilerRunner
7   > Compilation error. See log for more details
8
9* Try:
10> Run with --stacktrace option to get the stack trace.
11> Run with --info or --debug option to get more log output.
12
13BUILD FAILED in 38s

Read that carefully and notice what it does not contain: any mention of your code.

This block tells you which task failed, not what is wrong. :app:compileDebugKotlin means "the step that compiles your Kotlin". So the real message — the e: line with your file and line number — is further up the log, printed before this summary.

This is the single most common way beginners get stuck: they read the bottom of the log, find nothing useful, and conclude the error is unreadable. Scroll up. It is always up.

Two task names worth recognising, because they tell you which half of the project is unhappy:

• :app:compileDebugKotlin — your Kotlin. Look for e: lines above.
• :app:processDebugResources — your res/ folder. Look for AAPT: error: above.

Anatomy 3 — a crash

Your app builds, installs, opens, and then vanishes back to the home screen. Open Logcat and you will find something like this:

1FATAL EXCEPTION: main
2Process: com.yourname.hellopocket, PID: 12043
3java.lang.IndexOutOfBoundsException:
4    Index 3 out of bounds for length 3
5    at com.yourname.hellopocket.Greeting(MainActivity.kt:26)
6    at com.yourname.hellopocket.MainActivityKt.render
7    at androidx.compose.runtime.ComposerImpl.doCompose
8    at android.app.ActivityThread.main(ActivityThread.java:8757)

Four parts:

1. FATAL EXCEPTION: main — the app has stopped. "main" is the thread the screen runs on.
2. The exception type and message — IndexOutOfBoundsException, and helpfully Index 3 out of bounds for length 3. You asked for item 3 of a list that only has items 0, 1 and 2.
3. The stack trace — the trail of function calls that led here, most recent first.
4. The line that matters — the topmost line containing your own package name. Here that is com.yourname.hellopocket.Greeting(MainActivity.kt:26).

Everything below your line is Android's own machinery. It is not broken. It is just the road your mistake travelled down.

The three rules

1. Read the first error, not the last.

One missing brace can produce eighteen errors, because the compiler carries on trying to make sense of a file that stopped making sense at line 12. Errors two through eighteen are consequences. Fix number one and rebuild — most of the rest disappear with it.

2. Find your own file name.

If a message mentions androidx, kotlin.jvm or android.app, it is describing where your mistake landed, not where you made it. Keep scanning for a file you wrote.

3. Change one thing, then rebuild.

Two changes at once, and a fixed build tells you nothing about which one helped. This matters more here than on a laptop, because each build costs you real minutes and a slot from your allowance.

When you genuinely cannot tell

A short checklist that solves a surprising share of mysteries:

• Did you save? Pocket Studio usually saves as you type, but check.
• Is the reported line the line you were editing? If not, look at what you edited anyway.
• Count the brackets on the line above the reported one. Expecting '}' almost never means the problem is where it says.
• Read the message out loud. Argument type mismatch: actual type is 'Int', but 'String' was expected is completely plain English once spoken.
• Undo back to the last version that worked. Then redo one change at a time. This is unglamorous and it works every single time.

Notice that "ask an AI" is not on that list. It is a legitimate tool and you will use it eventually. But an assistant that answers before you have read the message trains you out of the exact skill this lesson exists to build.