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]