Re: [FFmpeg-devel] [RFC] Advanced Error Codes

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2759 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".