[jherico]

I'll certainly grant that unchecked exceptions are problematic for static analysis, but in regards to your second point, I don't feel like Rust has actually avoided creating "a separate syntax". It's created a different, more complex syntax which must be adopted inline in your actual normal code path, obfuscating what your code is actually expected to do under non-error conditions.

IMO, one of the most valuable pieces of exception handling is a distinct separation between your error logic and your non-error logic, which makes methods easier to comprehend. I also feel like the existence of the ? syntax is a dead giveaway in this regard because it's a fig-leaf trying to cover up the most egregious parts of the code where you'd otherwise have to be write the frequent "if error then early return error" statements which plague Golang.

[pcwalton]

The main reason behind the panic/Result distinction is that systems programmers, particularly those working in embedded, want to be able to turn off unwinding support entirely. Unwinding adds control flow edges everywhere, inhibiting optimizations, and it either adds code size bloat for the unwind tables or runtime overhead at every function call, depending on how it's implemented. I don't know of any way to implement exceptions that doesn't have this overhead. So although I like exceptions myself, I agree with Rust's decision not to embrace them in its domain.

[dragonwriter]

> but in regards to your second point, I don't feel like Rust has actually avoided creating "a separate syntax"

It avoids creating a separate syntax from the usual return-type declaration syntax for declaring the existence of errors, when compared to checked exceptions.

It also avoids creating a separate syntax for error handling, compared to (checked or unchecked) exceptions (pattern matching is ubiquitous in Rust for other purposes).

> It's created a different, more complex syntax which must be adopted inline in your actual normal code path, obfuscating what your code is actually expected to do under non-error conditions.

Pattern matching isn't an additional syntax (indeed, many languages with exceptions also have it), and it (IMO) does less to obscure non-error code than the visual noise of handling errors with try/catch.

It is more visual noise in the case of functions that do the equivalent of not handling exceptions, compared to exception-using langauges where that is implicit.