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

[Rémi Denis-Courmont]

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