Runtime overhead was already mentioned, but it's not the only reason. Implicit (unlike Java's throws declarations) exceptions fit well into a particular error-

Runtime overhead was already mentioned, but it's not the only reason. Implicit (unlike Java's throws declarations) exceptions fit well into a particular error-handling strategy of handling some expected errors, but by default, crashing the whole app on any unexpected error. It works pretty well for some applications, especially for web apps that operate on request-response model and have no local state: nothing could be easier than simply crash the VM, send the error report and restart the app back again. However, this strategy doesn't fit all possible situations. Example, you may need to know when something can throw so you would be able to roll back to a valid state. Often, what you want from a call to some third-party code is to explicitly define all possible error conditions that it can return. Java's `throws` handles that in some regard, but `Option` or 'Maybe` or `Result` monad (which has a lot of different names in different languages) is easier to reason about, and since it is usually implemented in languages that have pattern matching syntax, it also looks read to easier, more readable code, at least in my opinion. Now, I have to admit that ? and ! syntax sugar in Rust look very exception-like, and when I wrote web apps with it, I found myself having absolutely the same mindset as I had with exceptions. With one important difference: if I would be so inclined, I could have very easily gone through all the codebase and made all error handling much more strict and explicit. Regardless of how giant the codebase would become, the type checker would have my back in this process, and if I didn't want to leave some unknown error condition left behind in the depths of the call stack, it wouldn't be.