[dbaupp]

It doesn't necessarily take down the whole program, ice. it's recoverable, unlike memory corruption or a segfault.

(Yes I know you can install signal handlers for segv, but that is not isolated at a language level like a task failure is with Rust.)

[sisalcat]

Yes, I can catch SIGSEGV. And I can catch Java NullPointerExceptions and ArrayIndexOutOfBoundsExceptions. So Java prevents all crashes, lol.

[dbaupp]

Yes, Java applications are rarely killed by the OS/memory manager for trying to access memory they don't have control over.

[azth]

Don't argue with him/her, the parent poster is clearly acting immature.

[sisalcat]

That's a strange definition of "crash" you have there. I should go tell my customers next time that their programs definitely didn't crash.

[alkonaut]

Java raises an exception. If you handle it in code, the app does not crash. The crash is a consequence of failure to handle and recover from the exception.

Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway. What you can do though is try to clean up things, show a polite message and shut down the application in a semi-controlled way.

"Preventing crashes" isn't the best description of Rust's novel protection systems. In my opinion, the best part is providing guarantees about data integrity and security, e.g. preventing heartbleed type read-overruns and preventing data races in concurrent code due to shared mutable state.

[AlisdairO]

It's not that uncommon to want to recover from NPEs in a webapp environment. You want your thread of execution to error out, return a 500, and rollback whatever db changes it's made, but you want the webapp as a whole to keep running.

[lucian1900]

And this is precisely what task failure in Rust lets you do. Requests run in tasks, if the task fails, show an error message and make a new task for the next request.

[alkonaut]

Of course when you have a web application running requests using some thread pool or even more lightweight worker, then what we call the "application" is likely the request and you most likely don't want to kill the app server because you have good reason to believe the other requests are unaffected by the failing requests.

[coldtea]

>Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway.

Actually it can be quite common, especially in complex web / network programs with many components. In Java such errors do not corrupt memory like in C, and since they are isolated, no reason not to continue the operation of the overall program. The error could just be due to a resource not being found, or faulty input coming from outside -- that is, nothing that prevents you from continuing to work on other requests.

That's somewhat like Erlang handles the case, if I am not mistaken.