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

[Rémi Denis-Courmont]

On Fri, 31 Jul 2009 09:54:12 +0200, Olivier Aubert
<olivier.aubert at liris.cnrs.fr> wrote:
> 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.

Let me clarify. If we had only "void" function, I would have no problems
for exception-given languages. Some function had error return values in
*addition* to exception, some did not. It was a mess.

>> 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 applicable to functions returning values.
> What is your plan here?

We need to study this on a case by case basis. If a function really has no
good error value - that is outside the range of otherwise legal values, I
see no option but to return an int for error handling and pass the result
through a pointer in case of success. I readily admit that I have not
reviewed the entire API set as yet.

-- 
Rémi Denis-Courmont