2014-09-29 21:06 GMT+04:00 Nicolas George <geo...@nsup.org>: > 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)?
"A" first. It will ease user support a lot: now we have users asking "why system doesn't work (e.g. doesn't dumps RTSP media stream) and says "Invalid data ..." (which is decoded error reason returned from avformat_open_input() or av_read_frame()) ?" and we need to turn on debug logging and/or even sniff traffic to figure out the reason. And compare it with better situation when system gives something exact for cases of "401 Unauthorized", "404 Not Found", giving a smart user an idea to check his settings and giving technical support an idea what to advise to not-so-smart user. It is easier to implement than dumping some amount of latest errors related to certain AVFormatContext (or maybe better errors+warnings? or errors+...+debug? AFAIR nothing special is printed out for a lot of specific 40x cases, and debug loglevel is the one which is likely to dump reasonable amount of network messages exchange.) "B" usage will appear automatically when it gets possible, i believe. I didn't think about that actually, thanks for the idea. "C" was not considered. Thank you for your thoughts regarding GError. I think it could be useful to have error storage to be like a stack; both initial (the most low level) and last (the highest level) entries will be preserved, and also almost complete stack trace will be here, which will help in debugging. This way it gets not so important that every act of returning of error value up by stack is accompanied by storing error in the context. The downside is a big amount of places in code to edit. -- Andrey Utkin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
