[FFmpeg-devel] [PATCH] Add av_file_get_size() and av_file_read(), replace cmdutils.h:read_file().

[Nicolas George]

Le decadi 30 frimaire, an CCXIX, Stefano Sabatini a ?crit?:
> The problem is that the external function doesn't know the context of
> where the error occurred, and an error code is not enough, for example
> to distinguish if the error occurred in open(), lstat(), mmap() or if
> the file was too big (in this case an AVERROR(EINVAL) error code
> doesn't give a clue about the exact failure reason).
> 
> I spent unnamerable hours figuring out the meaning of lame error
> messages which provided no hint about where the failure occurred, so
> as a software user I tend to give *much* importance to these usability
> issues.

I have already met problem you are discussing here, as well as probably most
programmers.

The core of the problem resides in the fact that "error reporting" covers
two similar but fundamentally distinct tasks:

1. reporting to the calling context a simple cause so it can hopefully be
   recovered (EAGAIN/EINTR, EEXIST vs. EACCESS, etc.);

2. reporting to the used a detailed cause for the error so he can understand
   the problem and fix it.

The errno system works because libc functions are low-level and perform only
a simple task each: for example if opening a file fails, the calling context
knows which file was being opened.

Anything higher-level that wants to use integer error codes imitating the
errno system will stumble on the problem sooner or later.

Gtk+ has a nice way of solving the problem. Error causes are reported
through an additional "GError **" argument to each function that can
possibly fail. The GError structure has both an integer error code
(actually, a pair of integer error codes, allowing different parts of the
library to define new error codes independently) for automatic handling and
a human-readable string.

Libav* could possibly imitate the solution. Of course, adding an extra
argument to all existing functions is not an option, but new functions could
benefit from it. Something like that maybe:

- Add an AVError structure in avutil.

- New functions that can have something subtle to report take an additional
  pointer to an AVError. If it is null, the human-readable messages
  automatically goes to av_log.

- AVFoobarContext and similar structures gain an AVError field, so that
  whenever there is a context available, there is a place to store the
  error.

What do you think abut it?

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101221/6fe1d0a2/attachment.pgp>