Great!

Posted May 16, 2015 16:18 UTC (Sat) by ncm (guest, #165)
In reply to: Great! by ms_43
Parent article: Rust 1.0 released

When the response to failure is to run destructors, then the failure response code is exercised on every run of the program. In a well-designed system, the code that runs only on failure is very small, and runs on all failures, so is easy to exercise.

On rust, which doesn't have exception handling, programs idiomatically use standard library components to effectively emulate exception handling. These library components are simple and well-tested. It does depend on the whole system returning Result and Option objects for operations that can fail. I don't know how disruptive it would be to change a low-level function that once could not fail to one that returns a Result.

It is worth noting that the 1.0 release asserts a stable core language, but the library is not declared stable.

Great!

Posted May 16, 2015 21:57 UTC (Sat) by roc (subscriber, #30627) [Link] (2 responses)

The problem is that in most languages, error paths tend to leave your state in a half-done mess.

Also, you'd better be sure your destructors don't trigger allocation directly or indirectly.

Neither of those issues are tested "on every run of the program".

Great!

Posted May 19, 2015 13:34 UTC (Tue) by dgm (subscriber, #49227) [Link] (1 responses)

This is hardly a problem with the language, but with the code written in it, or more exactly, with the coder that wrote it. It's not difficult (even if tedious) to keep in mind your invariants, and rewind changes in case of failure. My personal experience is that the easiest way to do it is follow commit semantics (which for the uninitiated means not changing object's state until no exceptions can be raised).

Great!

Posted May 21, 2015 5:08 UTC (Thu) by roc (subscriber, #30627) [Link]

In practice, following commit semantics for large complex modules is too difficult and/or too expensive at run-time.

Ultimately all bugs are "problems with the coder that wrote it", but coders aren't perfect and their time isn't free, so making coding easier matters.