Exception handling (programming): Difference between revisions

Revision as of 18:02, 4 July 2025

Revision as of 13:36, 7 July 2025

Line 141:

Although exceptions in Eiffel have a fairly clear philosophy, Kiniry (2006) criticizes their implementation because "Exceptions that are part of the language definition are represented by INTEGER values, developer-defined exceptions by STRING values. [...] Additionally, because they are basic values and not objects, they have no inherent semantics beyond that which is expressed in a helper routine which necessarily cannot be foolproof because of the representation overloading in effect (e.g., one cannot

differentiate two integers of the same value)."<ref name="Kiniry"/>

[[C++26]] adds support for contracts, which are used as follows.<ref>{{cite web|url=https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2900r14.pdf|title=Contracts for C++|date=13 February 2025}}</ref>

<syntaxhighlight lang="cpp">

int f(const int x)

pre (x != 1) // a precondition assertion

post(r : r == x && r != 2) // a postcondition assertion; r names the result object of f

{

contract_assert (x != 3); // an assertion statement

return x;

}

Each contract

<syntaxhighlight>

== Uncaught exceptions ==

Line 154 ⟶ 166:

== Checked exceptions ==

[[Java (programming language)|Java]] introduced the notion of checked exceptions,<ref>{{cite web |url=http://answers.google.com/answers/threadview?id=26101 |title=Google Answers: The origin of checked exceptions |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110806090553/http://answers.google.com/answers/threadview?id=26101 |archive-date=2011-08-06 }}</ref><ref>Java Language Specification, chapter 11.2. http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2 {{webarchive|url=https://web.archive.org/web/20061208042454/http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html |date=2006-12-08 }}</ref> which are special classes of exceptions. SpecificallyIn Java, a checked exception specifically is any <code>Exception</code> that does not extend <code>RuntimeException</code>. The checked exceptions that a method may raise must be part of the method's [[Type signature|signature]]. For instance, if a method might throw an {{Java|IOException}}, it must declare this fact explicitly in its method signature. Failure to do so raises a compile-time error. This would be declared like so:

<syntaxhighlight lang="Java">

Line 192 ⟶ 204:

<syntaxhighlight lang="C++">

void performLogicalOperationperformSomeOperation(int a, int b) throw(std::invalid_argument, std::domain_error) {

// ...

}