On 17/06/2015 06:20, Marvin Humphrey wrote:
I definitely agree that from host languages other than C and Go, such
error conditions should trigger an exception.
For Go, it would make sense to map some error conditions to return values and
some to panic. Most if not all of the existing THROW calls within the
Clownfish runtime represent unrecoverable situations and should panic.
My question is whether assertions should be propagated via longjmp-based
exceptions or return values, or whether we should simply abort(). Using
longjmp may leak memory but in the case of unrecoverable errors it shouldn't
matter. Using return values seems unrealistic to me. For example,
cfish_dec_refcount throws an error if it's called on an object with zero
refcount. If we wanted to handle such a condition with return values, it
should return a "MAYBEuint32_t". This means that every call to DECREF must
check this return value and, for projects that don't want to throw exceptions,
propagate it. This seems rather silly for an error that can only be handled
with appropriate logging and program termination.
Also, we might want to add assertions at a later time. In some cases, this is
impossible without breaking the API (unless we make every method return a
MAYBE type).
But
things such as I/O errors would be handled with an exception in Python and a
return value in Go.
I agree that MAYBE types are a great solution for I/O errors.
For C, though, it's an interesting question. The C standard library will
never throw an exception.
But there are unrecoverable errors that glibc handles via printf/abort, like
"double free or corruption" if free() is called with an invalid pointer.
abort() immediately breaks into the debugger giving you a full stack trace
from the exact location of the error. OTOH, this only reports a trace of the C
call stack and discards the host language's call stack. A better solution
would probably be to throw an exception with a full C stack trace from
something like libunwind.
It's possible to offer the same guarantee for the
Clownfish runtime. Here's a blog post which illustrates why such guarantees
can be valuable:
http://250bpm.com/blog:4
Why should I have written ZeroMQ in C, not C++ (part I)
It would be interesting to know how ZeroMQ handles assertions.
Ensuring that the Clownfish runtime itself never throws exceptions -- even
though it may support them -- allows us to accommodate both this use case and
the similar Microsoft/Proton use case.
I think we have to distinguish between different kinds of errors.
- Assertions
- OOM errors
- Other errors
As explained before, I'm against handling assertions with return values. If a
user insists on a Clownfish runtime that never throws exceptions, we could add
an option to ignore assertions. But I can't see why someone would want to do
that. I think that our current exception mechanism is well-suited for
assertions. A user of the C library can decide whether to trap assertions, for
example to log them before terminating. If they aren't trapped, they result in
abnormal program termination which should always be better than ignoring them.
The only thing we might want to add is better stack trace information.
(There are some kinds of assertions for which it makes sense to disable them
in production builds for performance reasons. I'm open to adding a second type
of assertions that is only enabled in debug builds.)
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.
MAYBE types change the equation and make it possible to support the
no-exceptions use case. The cost is to make programming with
Clownfish-flavored C more cumbersome -- though programming with
Clownfish-powered libraries from any other host language would remain
unchanged.
Another problem is that ignoring return values can hide errors. I really want
to make Clownfish attractive for developers that care more about ease of
development. What do you think about having an option to unwrap return types
automatically?
Nick
