# Errors and Logs

## Key idea

Errors, stack traces, and log output are *exactly* the kind of thing chat models excel at parsing. A transformer's attention is built for finding the relevant token among (machine generated) noise. Use it!

Errors and logs are the canonical copy-paste use case of World 1. The trick is pasting *enough* context but not *too much*, and being explicit about what you were trying to do.

## Key goals

- Recognize when a chat is the right tool for an error or log
- Paste the right amount of context (neither too little nor too much)
- Frame the paste so the model can give a useful answer, not a guess
- Use the answer as a starting point, not gospel

---

## Why chat is the right mode here

A typical Python traceback is 10–40 lines of mostly noise with one or two lines of actual signal. A 500-line server log has maybe three lines that matter. Two reasons chat works here:

1. **The output is words, not code-in-place.** You are looking for an explanation or at least a pointer, not an edit to a file. Chat is the stronger choice. 
2. **The input is self-contained.** You can paste the whole error and the model can reason about it without needing your project layout, history, or build state.

An in-project chat can handle errors well too — and is often the right tool, because it can see the file that threw the error without you pasting it. For a long traceback or a multi-page log that doesn't fit cleanly in your editor's chat panel, or when the failure involves output from a server or system that isn't part of your project, a web chat's room to expand and your ability to copy-paste freely make it the better choice.

## What to paste

A good practice is to follow these three simple rules:

### 1. Paste the whole relevant block, not just the last line

The first line of a Python traceback ("File X, line Y, in foo") matters as much as the last line ("ValueError: ..."). Most stack traces tell a small story: *here's the path the program took to reach the error.* The model needs the path, not just the destination.

**Bad:**

```
ValueError: cannot convert string to float
```

**Better:**

```
Traceback (most recent call last):
  File "analyze.py", line 47, in <module>
    df["temp"] = df["temp"].astype(float)
  File ".../pandas/core/series.py", line 5816, in astype
    ...
ValueError: could not convert string to float: 'N/A'
```

The second version makes the cause (the string `'N/A'` in the data) obvious. The first leaves the model guessing.

### 2. Trim only when you have to

The advice you'll often hear is "trim aggressively before pasting." In practice, modern chat models are very good at finding the few relevant lines in a noisy log — that's exactly what attention is for. For a typical few-hundred-line log, pasting the whole thing usually works fine, and trimming buys you little.

Trimming is worth the effort in three specific cases:

1. **The log is large enough to bump against context limits** (tens of thousands of lines, or a multi-megabyte file). Here you have no choice — use `grep`, `tail`, or your editor to cut it down.
2. **The noise is the *kind* that misleads** — unrelated red `ERROR` lines from a different service, deprecation warnings that look like the failure but aren't, repeated retries that bury the original cause. A model will sometimes latch onto the loudest-looking line rather than the actual one.
3. **You want a faster, cheaper turn.** Less input means less to read and quicker iteration.

Outside those cases, don't agonize over it. If you do not know which part is relevant, paste a reasonable chunk and *say so*: "I think the failure is somewhere in here but I'm not sure where to look." The model will find it.

### 3. Include the command or code that triggered it

The model can analyze a traceback in a vacuum, but answers improve a lot when it knows what you were running. Even a single sentence helps:

> "I ran `python analyze.py temperatures.csv` and got this:"

That tiny preamble lets the model relate the error to the code path you exercised.

## What to say *around* the paste

A useful pattern is three short lines plus the paste:

> What I was trying to do.
> What I expected to happen.
> What actually happened (with the paste).

For example:

> I'm trying to load a CSV of furnace temperatures into a DataFrame and convert the temperature column to float. I expected the conversion to work. The file looks clean. Instead I'm getting this:
>
> ```
> Traceback ...
> ValueError: could not convert string to float: 'N/A'
> ```

This is enough for the model to land on the right answer (some rows have `'N/A'` strings) and suggest the right fix (handle the missing values explicitly).

If you've already tried things, say so. *"I tried `pd.read_csv(..., na_values='N/A')` and it didn't change the error."* This saves the model from suggesting what you already ruled out.

## What to do with the answer

The model's first answer to an error is often *plausible but wrong about the root cause*. It will identify the right neighborhood ("there is a non-numeric value in your column") but may guess wrong about the specific row or the fix that works in your case. Treat the answer as a **search query**, not a firm result:

- Does the diagnosis match what you see in your data or code?
- Is the suggested fix one you can verify quickly (one line, one test)?
- If a suggested fix doesn't work, *say so* in the next turn and paste the new output. The second answer is usually much better because the first one ruled out a possibility.

The biggest mistake we often make with chat-based error help is treating the first response as *authoritative*. The right mental model is: the model gives you a focused hypothesis, but you do the verification.

## Common pitfalls

- **Pasting only the last line of the traceback.** The model can guess, but it's a guess. Paste the whole traceback.
- **Pasting a log so large it doesn't fit, or one whose noise actively misleads.** A few hundred noisy lines is fine; tens of thousands of lines, or a log full of unrelated-but-loud `ERROR` entries, is when trimming earns its keep.
- **Pasting code with no error message.** "Why doesn't this work?" without the actual failure makes the model invent failure modes. Always run the code and paste what happened.
- **Pasting proprietary code into a public chat.** See [section 06](../06-verifying-and-citing/) — what you paste, the service sees and may log. Match the chat to the sensitivity of the content.
- **Not iterating.** If the first answer is wrong, the second is usually better. Treat the conversation as a debugging session, not a single oracle query.

## A worked example

You run a script and see:

```
$ python train.py
Traceback (most recent call last):
  File "train.py", line 12, in <module>
    model = model.to("cuda")
  File ".../torch/nn/modules/module.py", line 1145, in to
    return self._apply(convert)
  File ".../torch/nn/modules/module.py", line 797, in _apply
    module._apply(fn)
  ...
RuntimeError: Found no NVIDIA driver on your system. Please check that you
have an NVIDIA GPU and installed a driver from http://www.nvidia.com/Download/index.aspx
```

**A bad prompt:**

> Why doesn't my code work? `RuntimeError: Found no NVIDIA driver`

**A better prompt:**

> I'm running a PyTorch training script on my laptop. I expected it to fall back to CPU if no GPU was available, but instead I'm getting this. Is there a way to make the script run on whatever device is available? Here is the full traceback:
>
> ```
> [full traceback as above]
> ```

The better prompt gets you a useful answer about the standard `device = "cuda" if torch.cuda.is_available() else "cpu"` pattern, with the specific fix for line 12 of your script. The bad prompt gets you a generic "install NVIDIA drivers" answer that doesn't help you on a laptop without an NVIDIA GPU.


## Exercises

> **Exercise 1:** Find a recent error you debugged. Reconstruct a "bad paste" (last line only, no context) and a "good paste" (whole traceback, what you were doing, what you expected). Try both in a chat. How different are the answers?

> **Exercise 2:** Take a log file from a real system you have run — even just a `pip install` that warned about something. Paste 50 lines unfiltered, then paste a `grep`-narrowed version of the same log. Compare the responses for usefulness.

> **Exercise 3:** Pick a real error and run a multi-turn debugging session. Paste the error, try the suggested fix, paste the new output, and continue until the issue is resolved or you understand why it cannot be. Note where the model's hypothesis shifted between turns.