some improvements to the errors finding section

Author: thomasWeise

README.md

@@ -36,6 +36,7 @@ Die Slides zum Kurs in deutscher Sprache können unter <https://thomasweise.gith
 11. [Der Datentyp `str`](https://thomasweise.github.io/programmingWithPythonSlidesDE/11_str.pdf)
 12. [`None`](https://thomasweise.github.io/programmingWithPythonSlidesDE/12_none.pdf)
 13. [Variablen: Wertzuweisung](https://thomasweise.github.io/programmingWithPythonSlidesDE/13_variablen_wertzuweisung.pdf)
+14. [Fehler im Kode mit Exceptions und IDE finden](https://thomasweise.github.io/programmingWithPythonSlidesDE/14_fehler_im_kode_mit_exceptions_und_ide_finden.pdf)
 
 ### 2.3. The Slides in English
 The slides for the course are available at <https://thomasweise.github.io/programmingWithPythonSlides> and also listed below.

bookbase

@@ -1,4 +1,4 @@
-\hsection{Interlude: Finding Errors in your Code with the IDE}%
+\hsection{Interlude: Finding Errors in your Code with the IDE and Exceptions}%
 \label{sec:errorsInIde}%
 %
 \gitLoadAndExecPythonAndErrors{variables:assignment_wrong}{}{variables}{assignment_wrong.py}{}%
@@ -101,44 +101,61 @@
 They help us to find errors in the code.
 Errors are common.
 They happen all the time.
-Every programmer sometimes makes a typo, accidentally switches the order of parameters of a function, stores a \pythonil{float} in an \pythonil{int} variable, and so on.
+All programmers make mistakes.
+Sometimes it's a typo.
+Sometimes we accidentally switch the order of parameters of a function.
+Sometimes we mix up \pythonils{float} and \pythonils{int}.
+Sometimes we make logical errors.
+Sometimes we misunderstood what the function that we are calling does.
+Sometimes we misunderstood the algorithm that we try to implement.
 Some errors are obvious and easy to fix.
-Some require more serious debugging (see \cref{sec:dunder:debugging}).
-In many cases, however, our \pgls{ide} can already show us what and where the mistake happened.
-
+Some errors can be discovered based on the error output of the program.
+Some errors require more serious \glslink{debugger}{debugging} to even spot them~(see \cref{sec:dunder:debugging}).
+In some simple cases like typos, however, our \pgls{ide} can already point us to the mistake.%
+%
+%
+\hsection{Finding the Error by using the Program Output and Exceptions}%
 In \cref{lst:variables:assignment_wrong}, we prepared program \textil{assignment_wrong.py}, a variant of \textil{assignment.py}~(\cref{lst:variables:assignment}) with an error.
-For the sake of the example, let us assume that the programmer made a type in line~12 of the program:
-They misspelled \pythonil{int_var} and \pythonil{intvar}.
+For the sake of the example, let us assume that the programmer made a typo in line~12 of the program:
+They misspelled \pythonil{int_var} as \pythonil{intvar}.
 Executing the program with the error leads to the output given in \cref{exec:variables:assignment_wrong}.
 
-The questions now are:
-How can we see this same error in our \pycharm\ \pgls{ide}?
-Could we have found this error even without executing the program?
-
-To answer these questions, we open the program \textil{assignment_wrong.py} given in \cref{lst:variables:assignment_wrong} in the \pycharm\ \pgls{ide}.
+We can also open the program \textil{assignment_wrong.py} given in the \pycharm\ \pgls{ide}.
 We execute this program manually by clicking on the \pycharmRun\ button or by pressing~\keys{\shift+F10} in \cref{fig:errorsInIde01runProgram}.
 As you can see, the output in the run window is the same as given in \cref{exec:variables:assignment_wrong}~(\cref{fig:errorsInIde02exception}).
-Reading this output is the \emph{first} way to find out what went wrong.
-The text that appeared tells us what went wrong and even suggests how to fix it.
+
+If a program crashes, then \emph{carefully} reading its output is always the \emph{first} way to find out what went wrong.
+Indeed, in our example, the text that appeared tells us what went wrong and even suggests how to fix it.
 It says:~\emph{\inQuotes{\pythonilIdx{NameError}: name \inSQuotes{\pythonil{intvar}} is not defined. Did you mean: \inSQuotes{\pythonil{int_var}}?}}
 This is already pretty clear.
-We accessed some variable (name), \pythonil{intvar}, which has not been defined or assigned.
+We accessed some variable~(a name), \pythonil{intvar}, which has not been defined or assigned.
 It simply does not exist.
+
 The \python\ interpreter then checks whether some similar name exists.
 It found that there is a variable named \pythonil{int_var}.
 Even more, it also tells us the exact file and line where the error occurred, namely in line~12 of file \textil{assignment_wrong.py}!
 With this information, we have a good chance of finding the mistake.
-The so-called \pythonil{Exception} \pgls{stackTrace} that it prints thus not just tells us the error, a probable cause, and the most-likely location that caused the error.
+
+The so-called \pythonilIdx{Exception} \pgls{stackTrace} that it prints to \pgls{stderr} thus not just tells us that there was an error.
+It even tells us a probable cause and the most-likely line of code that caused the error.
 We will discuss this topic in-depth later in \cref{sec:exceptions}, but even at this stage, the message here is pretty clear.%
 %
 \bestPractice{readErrorMessage}{Always carefully \emph{read} error messages. %
 They often provide you very crucial information where to look for the mistake. %
 Not reading error messages is wrong.%
 }%
 %
-In the run console of \pycharm, we click on the linked file location.
+\endhsection%
+%
+\hsection{Finding the Error by using the IDE}%
+%
+We found the error by executing the program, seeing that it crashed, and then reading the output.
+In the run console of \pycharm\ that presents the program output, we can even click on the linked file location.
 This takes us to where the error occurred in \cref{fig:errorsInIde03underlined}.
-When looking at this line, we notice that the incorrectly typed word is (and always was) underline with red color.
+
+The question is:
+Could we have found this error even without executing the program?
+Actually, when looking at the line to which the click took us, we notice that the incorrectly typed word is~(and always was) underline with red color.
 This should have told us already that something is fishy without the need to even run the program in the first place.%
 %
 \bestPractice{redUnderline}{%
@@ -157,7 +174,7 @@
 We can also click on that note, and  it takes us again to the dodgy line in \cref{fig:errorsInIde06errorsListToLine}
 
 The fourth method in which the \pycharm\ \pgls{ide} can help us to discover errors are small red marks at the right-hand side of our editor window, shown in \cref{fig:errorsInIde07errorMark}.
-Holding the mouse cursor over these lines will open a small view with the suggested error message.
+Holding the mouse cursor over these marks will open a small view with the suggested error message.
 
 The fifth way to get a list of potential errors in \pycharm\ is to click on the \pycharmErrorsButton~button in the side menu on the left-hand side or to press~\keys{\Alt+6}, as illustrated in \cref{fig:errorsInIde08sidebar}.
 This again takes us to the list of potential errors in \cref{fig:errorsInIde09sidebarToView}.
@@ -167,28 +184,48 @@
 Read error messages. %
 If your \pgls{ide}  -- regardless whether it is \pycharm\ or something else -- annotates your code with some marks, then you should check every single one of them.%
 }%
+\endhsection%
+%
 %
-These tools make it much much easier to find errors.
-You can guess the importance of such features also by how many different ways \pycharm\ implements to get you to click and investigate its list of proposed errors and warnings.
+\hsection{Summary}%
+Programmers make errors.
+We make errors.
+You are going to make lots of errors.
+Later and now.
+Even now, in very simple programs, we are going to make errors.
+This cannot be prevented.
+The question can only be how we deal with that.
+How can we minimize the number of errors that we are going to make?
+How can we maximize that chance to discover and fix errors?
+
+The answer is simple:~\emph{By using all the tools at our disposal.}
+We can use the output of programs to find errors after running the programs.
+And we can use our \pgls{ide} to find errors based on the hints it provides to us even before executing the programs.
+Both tools make it much much easier to find errors.
+You can guess the importance of error-finding features also by the fact that \pycharm\ implements the error hints in several different ways, in the hope to get you to click and investigate its list of proposed errors and warnings.
 As mentioned in \cref{bp:readErrorMessage,bp:redUnderline}, using the \pgls{ide} features for error discovery and detection is incredibly important.
+
 Even if your program executes as expected, there still might be hidden errors in the code.
-Sometimes, you cannot easily tell whether the output of a program is correct.
-And the output you see might actually be wrong.
+Sometimes, you can easily tell whether the output of a program is correct.
+Sometimes, you cannot.
+In some cases, an output that looks OK might still be wrong.
+
 Sometimes, there might be some incorrect instructions in your program that just weren't used in your last execution.
 So even correct program output does not guarantee that the program itself is correct.
 Therefore, always checking each and every piece of code that your \pgls{ide} marks as dodgy is very important.
 Make sure that you full understand all error and warning messages.
 
 Warnings can be important, too.
-They can indicate possible errors, potential problems with variable types, or missing required packages (see, e.g., \cref{sec:gitClonePycharm}).
-Always fix errors and warnings wherever possible (obviously).
+They can indicate possible errors, potential problems with variable types, or missing required packages~(see, e.g., \cref{sec:gitClonePycharm}).
+Always fix errors and warnings wherever possible~(obviously).
 Even where you deem the warnings as false-positives, try to fix them anyway.
 They could result from non-standard code formatting that still \inQuotes{works}, but may be confusing for readers of your code.
 You should always try to produce warning-free code.
 For every warning or error that you deem as not a problem, remember:
 On one hand, \emph{you} might wrong.
 On the other hand, having fewer warnings and false-positive suspected errors makes it easier to find the actual problem if an actual problem happens.%
 %
+\endhsection%
 \FloatBarrier%
 \endhsection%
 %