On 04/06/2015 20:13, Marvin Humphrey wrote:
On Thu, Jun 4, 2015 at 7:55 AM, Nick Wellnhofer <[email protected]> wrote:
I'd simply keep treating OOM errors as fatal.
It's my understanding that this is a deal-breaker for Proton. One of Proton's
use cases is in memory-constrained embedded systems, where it's expected to
handle OOM scenarios gracefully.
From a quick look, Proton doesn't propagate OOM errors all the way down, but
exhibits unspecified behavior. It doesn't crash but it treats OOM errors
rather randomly. Just look at how NULL returns from pn_strdup are handled, for
example. I'd prefer code that specifies exactly what happens in case of
errors, even if it aborts.
Non-fatal OOM handling is only one many Proton requirements and it's not
certain we can meet them all -- but I don't think it's out of the question to
make the Clownfish runtime completely exception free and it's worth
considering.
There's an easy way to make the Clownfish runtime exception free: Simply
convert every call to THROW into a printf/abort. Depends on the definition of
"exception", of course :)
I hope we can at least agree that exceptions indicating an irrecoverable
programming error (changing a Hash during iteration, for example) should not
be propagated via return values.
That includes Go, where at least some of the time we'd use return codes. It
makes sense to return a FileNotFoundError as a separate value -- but not an
OutOfMemoryError.
Yes, for I/O errors, it would be a great improvement to return an Err object
instead of throwing an exception.
It's unrealistic to expect that Clownfish applications always check for the
return value of methods like Vec_Push. Typically, they will just ignore it.
An unhandled OOM error only leads to hard-to-diagnose problems down the way.
I think that's the case when used from a host language where exceptions are
the norm. But with C, it's debatable.
I argue that even with C, it's better to abort in an OOM situation than to
return an error.
* OOM errors are rare.
* Most of the time, OOM errors are irrecoverable, anyway.
* They affect almost every code path.
* Checking for return values requires a lot of discipline from
all programmers down the call stack. If an error isn't handled,
debugging can become really hard. Especially, because OOM
errors often result from other programming errors that become
even harder to debug if an OOM condition is silently ignored.
* abort()ing gives a nice backtrace directly from the source of
the problem.
The nice thing about your proposal is that is forces the caller to handle
errors if a return value is used. For void methods, we could add the
warn_unused_result attribute. But I'd really like to free users of the
Clownfish runtime from handling OOM errors. We should make it optional, at
least. For example with a macro that makes methods unwrap MAYBE return types
automatically.
Nick
