[vlc-devel] Announce: brand new python bindings (ctypes-based)

[Olivier Aubert]

Hello

On Thu, 2009-07-30 at 12:33 +0200, Rémi Denis-Courmont wrote:
> On Thu, 30 Jul 2009 11:03:07 +0200, Olivier Aubert
> <olivier.aubert at liris.cnrs.fr> wrote:
> > - the (infamous for some) exception passing mechanism is quite useful to
> > automatize error checking and reporting. Should the new API aim at
> > removing exceptions in favor of more common idiom (return value/errno),
> > it could be more cumbersome to translate automatically. Care should be
> > taken here.
> 
> I found exception to be a mess both for exception-incapable languages (like
> C), which is not a surprise. I found it also rather inconvenient for
> exception-capable, as we anyway have return values.
I completely agree for the first part. The second part about
exception-capable languages is more arguable, but that's not really the
point here.

> My plan was to:
> 1/ get rid of the exception error code as it is nowhere used,
> 2/ use the return value of the function for error signaling,
> 3/ provide a per-thread error message to convey what's currently in the
> exception.
> 
> Then, I'll remove exception completely. It's up to each bindings whether
> they want to the convert error return and the error message into an
> exception, or use a purely functional model.
Looks OK to me, except for one case: what about functions returning
values? Your scheme works for void functions (that can then return an
error code), for functions returning pointers (that can return NULL in
case of error), but is not appliable to functions returning values.
What is your plan here?

The only concern I have is that all error-reporting mechanisms can be
automatically converted, and thus 1/ are properly documented 2/ are not
too heterogeneous.

Olivier