3 ms·

`OutOfMemoryError` is the root of unchecked exceptions, you can't put it everywhere because then it might as well be nowhere. Rust improves on this by using a

`OutOfMemoryError` is the root of unchecked exceptions, you can't put it everywhere because then it might as well be nowhere. Rust improves on this by using a different syntax for unchecked exceptions (`panic!` vs `Result`) which provides the benefit of discouraging unchecked without preventing it.

tsimionescu 6y ago
Aren't panics() in Rust unrecoverable in release builds? Except for this minor point, I agree - you can't really make a managed memory system without resorting to unchecked exceptions. Array index out of bounds is another good example of an almost unavoidable exception that would only pollute the code if it had to be checked everywhere (as is Null pointer exception, but that of course could be mitigated by not having nulls in the language).
- ragnese 6y ago
  I don't believe so, no. You can set panics to automatically abort, though. But that's opt-in. The real point is that panics are absolutely unchecked exceptions, but it's really awkward to catch them and the standard library and entire Rust ecosystem has a good, solid, culture around returning Results whenever reasonable. The problem with Java is that a bunch of people have no idea what they are "supposed" to do with the unhappy path parts of their programs.
  - tsimionescu 6y ago
    Well, as long as the option of disabling panic handling exists, and if it is somewhat widely used in real applications, library writers can't rely on panics as an error-handling mechanism, so generally they have to treat it as if panics can abort the program. I think the problem of deciding what to do on the unhappy path is often very difficult, a lot of the time much harder than the actual happy path. This is true regardless of the error reporting/bubbling mechanism.
- Guvante 6y ago
  There are unwind panics and abort panics, it is the choice of the one panicking. Also if you are a library maintainer the binary can choose to disable unwind panics completely. On the topic of array index out of bounds Rust provides three ways to do indexing `obj[i]` which panics on out of bounds, `obj.get(i)` which returns `Option<T>` and `obj.get_unchecked(i)` which is the C/C++ style "if I go outside the bounds of the array it is undefined behavior" (and thus is marked unsafe). The first avoids polluting and provides the easiest syntax, the second allows you to opt into "I don't know if this is in bounds" and the final one is designed for instances where you otherwise can prove the index is in bound to avoid the conditionals to check.

tsimionescu 6y ago

Aren't panics() in Rust unrecoverable in release builds? Except for this minor point, I agree - you can't really make a managed memory system without resorting to unchecked exceptions. Array index out of bounds is another good example of an almost unavoidable exception that would only pollute the code if it had to be checked everywhere (as is Null pointer exception, but that of course could be mitigated by not having nulls in the language).

ragnese 6y ago
I don't believe so, no. You can set panics to automatically abort, though. But that's opt-in. The real point is that panics are absolutely unchecked exceptions, but it's really awkward to catch them and the standard library and entire Rust ecosystem has a good, solid, culture around returning Results whenever reasonable. The problem with Java is that a bunch of people have no idea what they are "supposed" to do with the unhappy path parts of their programs.
- tsimionescu 6y ago
  Well, as long as the option of disabling panic handling exists, and if it is somewhat widely used in real applications, library writers can't rely on panics as an error-handling mechanism, so generally they have to treat it as if panics can abort the program. I think the problem of deciding what to do on the unhappy path is often very difficult, a lot of the time much harder than the actual happy path. This is true regardless of the error reporting/bubbling mechanism.
Guvante 6y ago
There are unwind panics and abort panics, it is the choice of the one panicking. Also if you are a library maintainer the binary can choose to disable unwind panics completely. On the topic of array index out of bounds Rust provides three ways to do indexing `obj[i]` which panics on out of bounds, `obj.get(i)` which returns `Option<T>` and `obj.get_unchecked(i)` which is the C/C++ style "if I go outside the bounds of the array it is undefined behavior" (and thus is marked unsafe). The first avoids polluting and provides the easiest syntax, the second allows you to opt into "I don't know if this is in bounds" and the final one is designed for instances where you otherwise can prove the index is in bound to avoid the conditionals to check.