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

Rémi Denis-Courmont remi at remlab.net
Fri Jul 31 12:40:20 CEST 2009

On Fri, 31 Jul 2009 10:52:53 +0200, Olivier Aubert
<olivier.aubert at liris.cnrs.fr> wrote:
> A possible suggestion: since it is intended anyway to have a per-thread
> error message variable, why not make it a per-thread struct (error code+
> error message), which would be always set in case of error (and .code
> would remain 0 if ok). Functions for checking error code status would be
> implemented (in fact, it would not even change a lot from current
> status: libvlc_exception_raised, libvlc_exception_get_message would
> simply be parameterless).

Currently, we do not use error codes. The exception structure supports it,
but there are no "users". I am not confident that we come up with a
meaningful and stable error code set anyway. Really error codes make sense
if and only if the application may be able to handle different errors from
the same function differently; otherwise an error message is sufficient.
Considering the current state, I have no reason to believe that this would
be the case.

Also, I know two common patterns for error codes:
* a global variable specifying the most recent error
  (0 = no error ever since last explicitly clear), and
* a common return type for all function
  (0 = no error in that function).

The first one is the C errno model. The second one is found in some
libraries, but requires the use of indirection alsmost whenever a function
returns something.

Last option: A global variable containing the error status of the last
function kind of sucks, IMHO. It might loose errors by accident, especially
when an API function internally uses other API functions.

Rémi Denis-Courmont

More information about the vlc-devel mailing list