On Wed, Jul 02, 2025 at 04:43:55PM +0200, Michael Niedermayer wrote: > Hi > > People are asking for better error codes > Heres a quick pseodocode design / implementation / brainstorming: > I hope iam not re-doing some past one but i didnt quickly find a past > discussion > > Observations. > Errors are for developers debuging or users resolving problems > We rarely care about more then 2-3 independant errors but we care about > their history like from where they came and how and what arguments caused them > We also care about the error free case being fast, really fast > We are lazy we dont want maintaince burden > We also dont want to deal with maintaining matching cleanup for each > generated error > > Idea 1 > + very simple > + fully compatible can be freely mixed with existing error codes > - needs a global table > + we never alloc, so we have no cleanup to do > + zero overhead for passing around as its just integers > > Idea 2 (Alternatrive) > This is exactly like Idea 1 but using thread local instead of a global > tabl > + No mutex > + no global table > + no denial of service if a thread blasts errors out while another has an > occasional error > - Thread local table > - More complex and slow to move errors accross thread boundaries > > For both ideas: > * New error codes are 64bit > * if they are trunctaed to 32bit they are a valid 32bit error code like > AVERROR(EIO) > * That means the new error codes are 32bit (existing error code for > compatibility) and > 32bit (a identifier into a fixed size table.)
[...]
After reading Nicolas reply i think this can be described in a different way:
I think there are
1. Messages (Human language but also nummeric information)
2. Error codes (categorizing errors, some of which are usefull to programs,
some to specific users)
3. Error instance identifiers (which identify the specific error and allow us to
associate messages and other things with it)
What my suggestion really was, is to expand error codes in a 100% compatible
way to become error instance identifiers.
Which can then be used to lookup additional information for this specific
instance of an error
Or you could see it like this:
before my suggestion:
returned errors are broad categories
after
returned errors are identifying a specific individual error (with input, URL
source code location call stack and anything one wants to add to teh struct)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
