diff --git a/Doc/Sd1/objectsClasses.xml b/Doc/Sd1/objectsClasses.xml
index 52108740ac5305f7d63ccd2231debad00acae3bc..379e4ad7457ab2bb7a3eb271b573e483f9e2687e 100644
--- a/Doc/Sd1/objectsClasses.xml
+++ b/Doc/Sd1/objectsClasses.xml
@@ -868,6 +868,217 @@ System.out.println("Perimeter=" + r.getPerimeter());</programlisting></td>
</informaltable>
</figure>
+ <qandaset defaultlabel="qanda" xml:id="sd1_qanda_missingReturn">
+ <title>Compile time error</title>
+
+ <qandadiv>
+ <qandaentry>
+ <question>
+ <para>Try to compile the following snippet:</para>
+
+ <programlisting language="java">public int getMinimum(int a, int b) {
+ if (a < b) {
+ return a;
+ }
+}</programlisting>
+
+ <para>You'll encounter a Missing return statement error. What's
+ wrong here?</para>
+ </question>
+
+ <answer>
+ <para>The compiler effectively complains about a missing <code
+ language="java">if</code> related path: In case of <code
+ language="java">b <= a</code> no return value has been defined.
+ There are two possible solutions:</para>
+
+ <orderedlist>
+ <listitem>
+ <programlisting language="java">public int getMinimum(int a, int b) {
+ if (a < b) {
+ return a;
+ } else {
+ return b;
+ }
+}</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>Less readable but still producing an identical
+ result:</para>
+
+ <programlisting language="java">public int getMinimum(int a, int b) {
+ if (a < b)
+ return a;
+ return b;
+}</programlisting>
+ </listitem>
+ </orderedlist>
+ </answer>
+ </qandaentry>
+ </qandadiv>
+ </qandaset>
+
+ <qandaset defaultlabel="qanda"
+ xml:id="sd1_qanda_staticCodeAnalysisUnreachable">
+ <title>Static code analysis</title>
+
+ <qandadiv>
+ <qandaentry>
+ <question>
+ <para>Consider the following snippet:</para>
+
+ <programlisting language="java">int count = 3;
+
+count++;
+
+if (count < 5)
+ return;
+ return;
+
+System.out.println("Failed!");</programlisting>
+
+ <para>This <xref linkend="glo_Java"/> code resembles the <link
+ xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
+ goto fail SSL bug</link>'s structural problem. Since <xref
+ linkend="glo_Java"/> does not (yet) offer <code>goto</code>
+ statements we use <code language="java">return</code> instead for
+ terminating the <quote>current</quote> context.</para>
+
+ <para>Copy this code into your <xref linkend="glo_IDE"/>
+ and:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>Explain the resulting error. What is wrong? How do you
+ correct this error?</para>
+ </listitem>
+
+ <listitem>
+ <para>Explain the <code language="java">count++</code>
+ statement's purpose.</para>
+
+ <tip>
+ <para>There is no <quote>real</quote> application logic in
+ the given code. This example is meant to explain formal
+ <xref linkend="glo_Java"/> language features. What happens
+ if you correct the compile time error and in addition purge
+ the <code language="java">count++</code> statement?</para>
+ </tip>
+ </listitem>
+
+ <listitem>
+ <para>What is the underlying idea of these warning and error
+ messages?</para>
+ </listitem>
+ </orderedlist>
+ </question>
+
+ <answer>
+ <orderedlist>
+ <listitem>
+ <para>Like in the <link
+ xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
+ goto fail SSL bug</link> the code is poorly indented. Using
+ your <xref linkend="glo_IDE"/>'s auto indenting feature (Do
+ it!) you get:</para>
+
+ <programlisting language="java">int count = 3;
+count++;
+
+if (count < 5)
+ return;
+return;
+
+System.out.println("Failed!");</programlisting>
+
+ <para>The second <code language="java">return</code> statement
+ will leave the given context unconditionally regardless of the
+ preceding <code language="java">if (count < 5)</code> and
+ the <code language="java">count</code> variable's value in
+ particular. Thus the final <code
+ language="java">System.out.println("Failed!") statement</code>
+ being unreachable results in a compile time error.</para>
+
+ <para>Removing the erroneous second <code
+ language="java">return</code> statement resolves the error
+ leaving us with happily compiling code:</para>
+
+ <programlisting language="java">int count = 3;
+count++;
+
+if (count < 5)
+ return;
+
+System.out.println("Failed!");</programlisting>
+
+ <para>Conclusion: The <link
+ xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
+ goto fail SSL bug</link> could not have been occurring in
+ <xref linkend="glo_Java"/> due to an inherent language
+ feature. </para>
+ </listitem>
+
+ <listitem>
+ <para>Removing <code language="java">count++</code> leaves us
+ with:</para>
+
+ <programlisting language="java">int count = 3;
+
+if (count < 5) <co linkends="sd1_callout_staticIfAlwaysTrue-1"
+ xml:id="sd1_callout_staticIfAlwaysTrue-1-co"/>
+ return;
+
+System.out.println("Failed!");</programlisting>
+
+ <calloutlist>
+ <callout arearefs="sd1_callout_staticIfAlwaysTrue-1-co"
+ xml:id="sd1_callout_staticIfAlwaysTrue-1">
+ <para>Compiler warning: <emphasis role="bold">Condition
+ 'count < 5' is always 'true'</emphasis>.</para>
+ </callout>
+ </calloutlist>
+
+ <para>This warning is due to static compile time code
+ analysis: The <code language="java">count</code> variable's
+ value is not being altered throughout its scope. It could
+ actually be declared as <code language="java">final int count
+ = 3 disallowing since no sub</code>sequent assignments occur.
+ Thus the <code language="java">return</code> inside the <code
+ language="java">if (count < 5)</code> clause will always be
+ executed.</para>
+
+ <note>
+ <para>Despite its simplicity having the count++ statement in
+ place defeats the compiler's ability to discover<code
+ language="java"> our variable count</code>'s value now being
+ 4 is still smaller than 5.</para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>This mechanism keeps programmers from coding carelessly:
+ Even the <code language="java">if (count < 5)</code>
+ statement is most likely an unintended bug.</para>
+ </listitem>
+ </orderedlist>
+
+ <important>
+ <para>Conclusion: Watch out for compiler warning messages and do
+ not ignore them!</para>
+
+ <para>In many cases compiler warnings reveal serious flaws.
+ Correction on average will save you cumbersome time debugging
+ your code.</para>
+
+ <para>Set your compiler / <xref linkend="glo_IDE"/>'s warnings
+ to a yet tolerable higher level.</para>
+ </important>
+ </answer>
+ </qandaentry>
+ </qandadiv>
+ </qandaset>
+
<section xml:id="sd1_sect_accessControl">
<title>Encapsulation and access control</title>
diff --git a/Doc/Sd1/statements.xml b/Doc/Sd1/statements.xml
index b6c4338754d1c27f747881191cc2a16fff14fbd4..13dc3bf1621b9d2d137d0233aa150d3d5d78d5ef 100644
--- a/Doc/Sd1/statements.xml
+++ b/Doc/Sd1/statements.xml
@@ -881,162 +881,6 @@ err = sslRawVerify(...); ...</programlisting></td>
</informaltable>
</figure>
- <qandaset defaultlabel="qanda"
- xml:id="sd1_qanda_staticCodeAnalysisUnreachable">
- <title>Static code analysis</title>
-
- <qandadiv>
- <qandaentry>
- <question>
- <para>Consider the following snippet:</para>
-
- <programlisting language="java">int count = 3;
-count++;
-
-if (count < 5)
- return;
- return;
-
-System.out.println("Failed!");</programlisting>
-
- <para>This <xref linkend="glo_Java"/> code mimics the <link
- xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
- goto fail SSL bug</link>'s structural problem. Since <xref
- linkend="glo_Java"/> does not offer <code>goto</code> statements
- we use <code language="java">return</code> instead for
- terminating the <quote>current</quote> context.</para>
-
- <para>Copy this code into your <xref linkend="glo_IDE"/>
- and:</para>
-
- <orderedlist>
- <listitem>
- <para>Explain the resulting error. What is wrong? How do you
- correct this error?</para>
- </listitem>
-
- <listitem>
- <para>Explain the <code language="java">count++</code>
- statement's purpose.</para>
-
- <tip>
- <para>There is no <quote>real</quote> application logic in
- the given code. It is an example meant to explain formal
- <xref linkend="glo_Java"/> language features. What happens
- if you correct the compile time error and in addition
- purge the <code language="java">count++</code>
- statement?</para>
- </tip>
- </listitem>
-
- <listitem>
- <para>What is the underlying idea of these warning and error
- messages?</para>
- </listitem>
- </orderedlist>
- </question>
-
- <answer>
- <orderedlist>
- <listitem>
- <para>Like in the <link
- xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
- goto fail SSL bug</link> the code is poorly indented. Using
- your <xref linkend="glo_IDE"/>'s auto formatting feature
- (how?) you get:</para>
-
- <programlisting language="java">int count = 3;
-count++;
-
-if (count < 5)
- return;
-return;
-
-System.out.println("Failed!");</programlisting>
-
- <para>The second <code language="java">return</code>
- statement will leave the context unconditionally regardless
- of the preceding <code language="java">if (count <
- 5)</code> and the <code language="java">count</code>
- variable's value in particular. Thus the final <code
- language="java">System.out.println("Failed!")</code>
- <emphasis role="bold">can</emphasis> never be reached
- resulting in a compile time error.</para>
-
- <para>Removing the erroneous <code
- language="java">return</code> resolves the error leaving us
- with happily compiling code:</para>
-
- <programlisting language="java">int count = 3;
-count++;
-
-if (count < 5)
- return;
-
-System.out.println("Failed!");</programlisting>
-
- <para>Conclusion: The <link
- xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
- goto fail SSL bug</link> could not have been occurring in
- <xref linkend="glo_Java"/> due to language features.</para>
- </listitem>
-
- <listitem>
- <para>Removing <code language="java">count++</code> leaves
- us with:</para>
-
- <programlisting language="java">int count = 3;
-
-if (count < 5) <co linkends="sd1_callout_staticIfAlwaysTrue-1"
- xml:id="sd1_callout_staticIfAlwaysTrue-1-co"/>
- return;
-
-System.out.println("Failed!");</programlisting>
-
- <calloutlist>
- <callout arearefs="sd1_callout_staticIfAlwaysTrue-1-co"
- xml:id="sd1_callout_staticIfAlwaysTrue-1">
- <para>Compiler warning: <emphasis role="bold">Condition
- 'count < 5' is always 'true'</emphasis>.</para>
- </callout>
- </calloutlist>
-
- <para>This warning is due to static compile time code
- analysis: The <code language="java">count</code> variable's
- value is not being altered throughout its scope. It could
- actually be declared as <code language="java">final int
- count = 3 disallowing sub</code>sequent assignments. Thus
- the <code language="java">return</code> inside <code
- language="java">if (count < 5)</code> will always be
- executed.</para>
-
- <para>Despite its simplicity having the count++ statement in
- place defeats the compiler's ability to discover that <code
- language="java">count</code> now having a value of 4 still
- being smaller than 5.</para>
- </listitem>
-
- <listitem>
- <para>The underlying idea is preventing programmers from
- coding carelessly: Even the <code language="java">if (count
- < 5)</code> statement is most likely an unintended
- bug.</para>
- </listitem>
- </orderedlist>
-
- <important>
- <para>Conclusion: Watch out for compiler warning messages and
- do not ignore them!</para>
-
- <para>In many cases compiler warnings reveal serious flaws.
- Correction on average will save you lots of cumbersome time
- debugging your code.</para>
- </important>
- </answer>
- </qandaentry>
- </qandadiv>
- </qandaset>
-
<figure xml:id="sd1_fig_ifElseNested">
<title>Nested <code language="java">if ... else</code></title>