Editing Structured programming (section)

=== Exception handling ===
{{further|Exception handling (programming)}}

Based on the coding error from the [[Cluster (spacecraft)|Ariane 501 disaster]], software developer Jim Bonang argues that any exceptions thrown from a function violate the single-exit paradigm, and proposes that all inter-procedural exceptions should be forbidden. Bonang proposes that all single-exit conforming C++ should be written along the lines of:

<syntaxhighlight lang="cpp">
bool MyCheck1() throw() {
  bool success = false;
  try {
    // Do something that may throw exceptions.
    if (!MyCheck2()) {
      throw SomeInternalException();
    }
    // Other code similar to the above.
    success = true;
  } catch (...) {
    // All exceptions caught and logged.
  }
  return success;
}
</syntaxhighlight>

Peter Ritchie<!--not the lawyer, don't wikilink--> also notes that, in principle, even a single <code>throw</code> right before the <code>return</code> in a function constitutes a violation of the single-exit principle, but argues that Dijkstra's rules were written in a time before exception handling became a paradigm in programming languages, so he proposes to allow any number of throw points in addition to a single return point. He notes that solutions that wrap exceptions for the sake of creating a single-exit have higher nesting depth and thus are more difficult to comprehend, and even accuses those who propose to apply such solutions to programming languages that support exceptions of engaging in [[Cargo cult programming|cargo cult]] thinking.<ref>{{cite web |title=Single-Entry, Single-Exit, Should It Still be Applicable in Object-oriented Languages? |website=Peter Ritchie's MVP Blog |date=7 March 2008 |url=http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx |access-date=2014-07-15 |url-status=live |archive-url= https://web.archive.org/web/20121114195652/http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx |archive-date=2012-11-14}}</ref>

David Watt also analyzes exception handling in the framework of sequencers (introduced in this article in [[Structured programming#Early exit|the previous section on early exits]].) Watt notes that an abnormal situation (generally exemplified with arithmetic overflows or input/output failures like file not found) is a kind of error that "is detected in some low-level program unit, but [for which] a handler is more naturally located in a high-level program unit". For example, a program might contain several calls to read files, but the action to perform when a file is not found depends on the meaning (purpose) of the file in question to the program and thus a handling routine for this abnormal situation cannot be located in low-level system code. Watts further notes that introducing status flags testing in the caller, as single-exit structured programming or even (multi-exit) return sequencers would entail, results in a situation where "the application code tends to get cluttered by tests of status flags" and that "the programmer might forgetfully or lazily omit to test a status flag. In fact, abnormal situations represented by status flags are by default ignored!" He notes that in contrast to status flags testing, exceptions have the opposite [[default (computer science)|default behavior]], causing the program to terminate unless the programmer explicitly deals with the exception in some way, possibly by adding code to willfully ignore it. Based on these arguments, Watt concludes that jump sequencers or escape sequencers (discussed in the previous section) are not as suitable as a dedicated exception sequencer with the semantics discussed above.{{sfn|Watt|Findlay|2004|pp=221–222}}

The textbook by Louden and Lambert emphasizes that exception handling differs from structured programming constructs like <code>while</code> loops because the transfer of control "is set up at a different point in the program than that where the actual transfer takes place. At the point where the transfer actually occurs, there may be no syntactic indication that control will in fact be transferred."<ref>{{cite book |author1=Kenneth C. Louden|author2=Kenneth A. Lambert|title=Programming Languages: Principles and Practices |year=2011|edition=3rd|publisher=Cengage Learning|isbn=978-1-111-52941-3|page=423}}</ref> Computer science professor Arvind Kumar Bansal also notes that in languages which implement exception handling, even control structures like <code>for</code>, which have the single-exit property in absence of exceptions, no longer have it in presence of exceptions, because an exception can prematurely cause an early exit in any part of the control structure; for instance if <code>init()</code> throws an exception in <code>for (init(); check(); increm())</code>, then the usual exit point after check() is not reached.<ref>{{cite book |author=Arvind Kumar Bansal|title=Introduction to Programming Languages|year=2013|publisher=CRC Press |isbn=978-1-4665-6514-2|page=135}}</ref> Citing multiple prior studies by others (1999–2004) and their own results, Westley Weimer and [[George Necula]] wrote that a significant problem with exceptions is that they "create hidden control-flow paths that are difficult for programmers to reason about".<ref>{{cite journal |year=2008|author1=Weimer, W. |author2=Necula, G.C.|name-list-style=amp|title=Exceptional Situations and Program Reliability|journal=ACM Transactions on Programming Languages and Systems|volume=30|issue=2 |doi=10.1145/1330017.1330019 |s2cid=3136431 |url=http://www.cs.virginia.edu/~weimer/p/weimer-toplas2008.pdf|url-status=dead|archive-date=2015-09-23 |archive-url=https://web.archive.org/web/20150923211739/http://www.cs.virginia.edu/~weimer/p/weimer-toplas2008.pdf|at=8:27<!--this is a single page number in the paper, where the quote is found-->}}</ref>

The necessity to limit code to single-exit points appears in some contemporary programming environments focused on [[parallel computing]], such as [[OpenMP]]. The various parallel constructs from OpenMP, like <code>parallel do</code>, do not allow early exits from inside to the outside of the parallel construct; this restriction includes all manner of exits, from <code>break</code> to C++ exceptions, but all of these are permitted inside the parallel construct if the jump target is also inside it.<ref name="Chandra2001">{{cite book|author=Rohit Chandra|title=Parallel Programming in OpenMP|year=2001|publisher=Morgan Kaufmann |isbn=978-1-55860-671-5|page=45}}</ref>