Hi Nicolas
On Tue, Aug 12, 2025 at 04:43:29PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-08-03):
> > well, you may have deep call stacks
> >
> > user_app->libavfilter->libavformat->libavcodec->decoder->jpeg_decoder->...
> >
> > and the user of the user_app needs to know what fil
Michael Niedermayer (HE12025-08-03):
> well, you may have deep call stacks
>
> user_app->libavfilter->libavformat->libavcodec->decoder->jpeg_decoder->...
>
> and the user of the user_app needs to know what file had what failure
> so the error details must pass through all this.
>
> Some of the A
Hi
On Tue, Jul 29, 2025 at 12:01:50AM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-07-06):
> > Hi Nicolas
>
> Hi. Sorry I procrastinated to reply to that too.
>
> > theres a fixed length array of AdvancedError structs.
>
> More global state is not a good idea.
>
[...]
> > * Th
Sorry, forgot a bit:
> The first group:
>
> - do not get a context;
>
> - perform a rather simple task;
- have a perimeter small enough that an error code is enough for the
caller to know what went wrong;
>
> - could be called in tight loops, even when they fail repeatedly, and
> theref
Michael Niedermayer (HE12025-07-06):
> Hi Nicolas
Hi. Sorry I procrastinated to reply to that too.
> theres a fixed length array of AdvancedError structs.
More global state is not a good idea.
> AdvancedError has a fixed length char field.
> Thats where a single custom text string can be stored
Hi Nicolas
On Fri, Jul 04, 2025 at 03:29:19PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-07-03):
> > return av_adv_err_new(AVERROR_INVALIDDATA, "Garbled foobar data", "Foo
> > triangle quantum decoder"
> > __FILE__, __LINE__, NULL, "Whaetver you like %s",
>
Michael Niedermayer (HE12025-07-03):
> return av_adv_err_new(AVERROR_INVALIDDATA, "Garbled foobar data", "Foo
> triangle quantum decoder"
> __FILE__, __LINE__, NULL, "Whaetver you like %s",
> favorite_food);
>
> teh return type is int64_t here
So we need to change all our
Hi
On Thu, Jul 03, 2025 at 10:56:39AM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-07-02):
[...]
> To be clear, you suggest, IIUC:
>
> - The developer registers the error code.
> - The developer writes the explanation for the error when registering
> the error code.
> - The devel
Michael Niedermayer (HE12025-07-02):
> its a bit fuzzy, for example
> AVERROR(EAGAIN) is for the program
> but AVERROR_PATCHWELCOME is for the developer
> while AVERROR_PROTOCOL_NOT_FOUND is for the one building the lib
> and a EOF is for the one supplying the input file
Indeed, but my point stand
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.
>
Hi Nicolas
On Wed, Jul 02, 2025 at 04:52:58PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-07-02):
> > People are asking for better error codes
>
> I have little time just now, but I think it is important to clarify:
>
> - Error CODES are for when the program must react specifical
Michael Niedermayer (HE12025-07-02):
> People are asking for better error codes
I have little time just now, but I think it is important to clarify:
- Error CODES are for when the program must react specifically to a
certain kind of error condition:
if (ret == AVERROR(EAGAIN)) …
- Error MES
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
13 matches
Mail list logo
