Introduction

When you catch an exception, the exception object usually gives you the type directly, while the file and line number come from its stack trace or traceback information. The exact API depends on the language, and the line number is only as good as the debugging metadata or traceback information that was preserved when the exception was thrown.

The three pieces of data come from different places

It helps to separate the concepts:

• the exception type comes from the exception object's class
• the file and line number come from stack-trace data
• the reported location is usually the throw site or the current traceback frame, not a magical root-cause oracle

That distinction matters because some environments strip file and line details in release builds or during rethrows.

Python example

In Python, the caught exception object tells you the type, and traceback lets you inspect frames and line numbers.

1import traceback
2
3
4def crash():
5    value = int("bad")
6    return value
7
8
9try:
10    crash()
11except Exception as exc:
12    print(type(exc).__name__)
13    frames = traceback.extract_tb(exc.__traceback__)
14    last = frames[-1]
15    print(last.filename)
16    print(last.lineno)

This prints the exception type, the file name, and the line number from the last traceback frame, which is usually the most relevant frame for the immediate error.

C# example

In C#, ex.GetType() gives you the type, and stack-trace objects can expose file and line information when debug symbols are available.

1using System;
2using System.Diagnostics;
3
4class Program
5{
6    static void Main()
7    {
8        try
9        {
10            Crash();
11        }
12        catch (Exception ex)
13        {
14            Console.WriteLine(ex.GetType().FullName);
15
16            var trace = new StackTrace(ex, true);
17            var frame = trace.GetFrame(0);
18            Console.WriteLine(frame?.GetFileName());
19            Console.WriteLine(frame?.GetFileLineNumber());
20        }
21    }
22
23    static void Crash()
24    {
25        throw new InvalidOperationException("broken");
26    }
27}

If the file name or line number comes back empty or zero, the code may be running without the symbol information needed to map IL offsets back to source files.

Java example

Java follows the same general pattern. The exception type comes from the object, and the stack trace contains source location information.

1public class Main {
2    public static void main(String[] args) {
3        try {
4            crash();
5        } catch (Exception ex) {
6            System.out.println(ex.getClass().getName());
7            StackTraceElement frame = ex.getStackTrace()[0];
8            System.out.println(frame.getFileName());
9            System.out.println(frame.getLineNumber());
10        }
11    }
12
13    static void crash() {
14        throw new IllegalStateException("broken");
15    }
16}

The first StackTraceElement is commonly the throw site, which is why it is often the one people inspect first.

Logging is usually better than printing ad hoc details

In real applications, the best move is usually to log the whole exception with structured context rather than manually printing just three fields. Logging frameworks preserve stack traces, nested exceptions, timestamps, and correlation information, which is far more useful during incident analysis.

Manual extraction is still useful for custom diagnostics, user-facing summaries, or unit tests that assert on exception metadata.

Be careful with rethrows and wrapped exceptions

The line number you see may reflect where the exception was rethrown or wrapped, not where the original failure began. Languages have different rules for preserving stack information, and wrapper exceptions often move the most useful detail into an inner or cause exception.

That is why production diagnostics should inspect the entire exception chain, not just the top-level object.

Common Pitfalls

• Assuming file and line number are always available in optimized or symbol-free builds.
• Looking only at the outer exception when the important details are in an inner exception or cause.
• Treating the first visible line number as the full root cause without reading the rest of the stack trace.
• Printing only a message string and discarding the stack information.
• Using language-specific APIs incorrectly by assuming every platform exposes the same exception metadata model.

Summary

• Exception type usually comes directly from the caught exception object.
• File and line number usually come from stack-trace or traceback data.
• Python, C#, and Java all expose this information through different APIs.
• Source line details may be missing when debugging metadata is unavailable.
• For real diagnostics, log the full exception chain instead of only a few extracted fields.