# [Tex/LaTex] why is this error message line number wrong

errors

I have this very short TeX file

\documentclass[12pt]{report}
\usepackage[a4paper,widh=100mm,top=50mm]{geometry}
\begin{document}
test
\end{document}


in which I have made an mistake writing widh instead of width. Now when I compile via pdflatex I would expect something like

! Error message: blablabala
l.2 \usepackage[a4paper,widh=100mm,top=50mm]{geometry}


which would help me spot the line in which the error originated in my source file (that would be the second line).

! Package keyval Error: widh undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
...

l.994 \ProcessOptionsKV[p]{Gm}


Why so?
Furthermore how is it supposed to be helpful to , not only not show the line in which the error occurred, but even to show a different line in a different file, which?

My take on it is that l.994 \ProcessOptionsKV[p]{Gm} is some codepart that was called with my data from line 2 and the error only occured then and that it fine, but why then would the message not in addition state the file and a backtrack / trace to the actual line?

# update to clarify the issue

I made some more testing and adapted the tex source to this

\documentclass[12pt]{report}
\usepackage[a4paper,widh=100mm,top=50mm]{geometry}
\errmessage{line three intentionally throws an error}
\begin{document}
\end{document}


which on purpose throws an error in the third line and the output shows then

/usr/share/texmf-dist/tex/latex/geometry/geometry.sty:994: Package keyval Error
: widh undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
...

l.994 \ProcessOptionsKV[p]{Gm}
%
)
./testerrorlinemadness.tex:3: line three intentionally throws an error.
l.3 ...e{line three intentionally throws an error}


clearly making the point that when raising the first error my source text file had not yet evaluated the third line and hence has imho no real excuse to **not to feature the current line number at occurrence of error*.

# Update, how would other languages handle error messages?

Since the comments and answers had a tendency to argue that it is completely natural and acceptable that the example feature would not report the more correct line number (the line where the error was provoked in the original tex file) I would like to show that other languages can indeed give a trace back to the point where the error occured.

To do so lets have a look at a short example how javascript would have handled a comparable error reporting task

// EXAMPLE how error message and propagation work in many another
// language (example javascript)
//
// description: what would be MACROS in latex such as /usepackage
// would be named FUNCTIONS in javascript.
// To keep with the example in latex and allow comparison
// we make up a two functions 1: "usepackage" and 2: "geometry"

function usepackage(parameter)
{
geometry(parameter);
}

function geometry(parameter)
{
ProcessOptionsKV=parameter.width.length;
}

// When now calling the usepackage correctly no error occurs
usepackage( {width:"12mm"} )

// But when providing wrong input, there is an error message
usepackage( {widh:"12mm"} )

// this is the error message
/*
Exception: TypeError: parameter.width is undefined
*/
// reading the message shows backtracingly line by line
// how the error came about. after the Error message it shows that
// the error occured in
// 1. function "geometry" in file "Scratchpad/1" line 16,
// which was called from
// 2. function "usepackage" in file "Scratchpad/1" line 11
// which was provided with the wrong input from
// 3. the file "Scratchpad/1" line 24
//


If you want a more informative error message you can increase \errorcontextlines

\errorcontextlines=200
\documentclass[12pt]{report}
\usepackage[a4paper,widh=100mm,top=50mm]{geometry}
\begin{document}
test
\end{document}


produces

! Package keyval Error: widh undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
...

\GenericError  ...
\endgroup
\KV@split ...x \KV@errx {\@tempa \space undefined}
\else \ifx \@empty #3\@emp...

\KV@do ...ax #1\@empty \else \KV@split #1==\relax
\expandafter \KV@do \fi
<argument> a4paper,widh=100mm,
top=50mm
\setkeys ... {KV@#1@}\let \@tempc \relax \KV@do #2
,\relax ,
\@ProcessOptionsKV ...keys {#2}{\@tempa }}\@tempa
\AtEndOfPackage {\let \@un...
l.994 \ProcessOptionsKV[p]{Gm}
%
?


This shows the macro expansion levels that lead to the error, by default LaTeX turns this off as it just exposes the implementation of the various commands that is not that interesting to most uses.

TeX has no record of where a particular macro was defined, only the definition that it has at the point of the error so it has no way of saying that the argument currently being processed by \ProcessOptionsKV was originally input from the line

\usepackage[a4paper,widh=100mm,top=50mm]{geometry}