Andrey Breslav
71 lines
3.1 KiB
Plaintext
71 lines
3.1 KiB
Plaintext
Exceptions in [Kotlin] are not very different from any other language. the main difference from *Java* is that there're no checked exceptions in [Kotlin], you can find out the motivation for this [below|#why].
|
|
|
|
h3. Exception classes
|
|
|
|
All exception classes in [Kotlin] are descendants of the class {{Exception}}. Every exception has a message, stack trace and an optional cause.
|
|
|
|
To *throw* an exception object, one uses the *throw* expression:
|
|
{jet}
|
|
throw MyException("Hi there!")
|
|
{jet}
|
|
|
|
To catch an exception, one uses the *try* expression:
|
|
{jet}
|
|
try {
|
|
// some code
|
|
}
|
|
catch (e : SomeException) {
|
|
// handler
|
|
}
|
|
finally {
|
|
// optional finally block
|
|
}
|
|
{jet}
|
|
As usual, there may be zero or more *catch* blocks, and *finally* may be omitted, but at least one *catch* or *finally* must be present.
|
|
|
|
Note that *try* is an _expression_, i.e. it may have a value:
|
|
{jet}
|
|
val a : Int? = try { parseInt(input) } catch (e : NumberFormatException) { null }
|
|
{jet}
|
|
The "returned" value of *try* expression with no *finally* is either the last expression in the *try* block or the last expression in the *catch* block (or blocks).
|
|
|
|
If *finally* block is present, its last expression is the value of *try* expression.
|
|
|
|
{anchor:why}
|
|
h3. Why [Kotlin] has no checked exceptions
|
|
|
|
People with *Java* background may wonder why [Kotlin] does not have checked exceptions. There's so much said on this topic, that we just provide a few citations and one example here.
|
|
|
|
Our example is {{java.lang.Appendable}} -- an interface from {{JDK}}, implemented by {{StringBuilder}}, that has, among others, the following method declaration:
|
|
{jet}
|
|
Appendable append(CharSequence csq) throws IOException;
|
|
{jet}
|
|
What does this signature say? It says that _every time_ I append a string to something (a {{StringBuilder}}, some kind of a log, a console, etc) I _have to_ catch those {{IOExceptions}}. Why? Because it _might be_ performing IO ({{Writer}} also implements {{Appendable}})... So it results into this kind of code all over the place:
|
|
{jet}
|
|
try {
|
|
log.append(message);
|
|
}
|
|
catch (IOException e) {
|
|
// Must be safe
|
|
}
|
|
{jet}
|
|
And this is no good, see [Effective Java|http://java.sun.com/docs/books/effective] Item 65: *Don't ignore exceptions*.
|
|
|
|
h4. Some citations from prior art:
|
|
|
|
Bruce Eckel says in [Does Java need Checked Exceptions? |http://www.mindview.net/Etc/Discussions/CheckedExceptions]:
|
|
{quote}
|
|
Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result -- decreased productivity and little or no increase in code quality.
|
|
{quote}
|
|
|
|
Other citations of this sort:
|
|
# [Java's checked exceptions were a mistake|http://radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html] (Rod Waldhoff)
|
|
# [The Trouble with Checked Exceptions|http://www.artima.com/intv/handcuffs.html] (Anders Hejlsberg]
|
|
|
|
h3. Java interoperability
|
|
|
|
Some details on *Java* interoperability are available [here|Java interoperability#Checked exceptions].
|
|
|
|
h3. What's next
|
|
|
|
* [Java interoperability] |