L'octidi 8 vendémiaire, an CCXXIII, Andrey Utkin a écrit : > At last I got back to this issue. > First I thought of adding such new error codes: <snip> > What do you think about it? Which would you prefer?
I am sorry to have to say your proposal has the taste of "add whatever I need for my specific use case, and if it can be useful for others lucky them". Which does not mean the proposal does not have merit, just that it is not obviously the best one. Before enhancing the error code system, I believe you must answer a few questions, and above all: What do you want more specific error codes for? Is it to provide the user with more accurate and less misleading error messages (A)? Is it to allow the application to react to specific errors (example: authentication failure => re-ask the password) (B)? Is it to allow part of the code to forward specific errors that can only happen in a that small area of code (C)? Something else? I quite like the GError system devised in GLib for the Gtk+ toolkit. It solves A, B and C in a rather elegant way IMHO. It works by passing a "GError **" to all functions that can return an error; if an error happens, the pointer is changed to a newly-allocated GError structure (memory allocation failure is considered fatal in GLib) to hold the error details. The GError structure has a (pointer to) human-readable error message, with more details than a constant text, it can hold file names, wrong values and ranges, etc. This solves A. The GError structure also has error codes, that makes B work; it uses a major/minor scheme, which solves part of C, but only part since the major needs to be registered globally. I am not saying we should imitate this point by point, but taking a few hints may help getting a good system. And of course, the systems needs to be compatible with the current "ret<0" scheme to allow incremental implementation. Another issue that I would like to enhance in the error system is to be able to find where an error originated: not the various "if(ret<0) return ret;" in the call stack but the actual "if(!foo) return AVERROR(errno);" check. If we have a place to store details about the error, storing __FILE__ and __LINE__ in it is easy. It seems to be that in most part of the code, we have some kind of AVObject structure, especially when logging: that would be an obvious place to store the error details. When there is not, a thread-local or global dummy AVObject can probably be used. Sorry for the rant. -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
