We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4179 - SDL_SetError floods my logs in debug mode
Summary: SDL_SetError floods my logs in debug mode
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: 2.0.8
Hardware: All All
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-27 17:41 UTC by beuc
Modified: 2018-07-16 16:46 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description beuc 2018-05-27 17:41:41 UTC
Hi,

I see that when using SDL_LOG_PRIORITY_DEBUG, SDL_SetError() not only sets the current error but also prints it out.
This sounds like a good idea at first, but in practice I get flooded by errors that I specifically handled in my code.
For instance, whenever I query SDL_GetColorKey, even when I handle the case when the result is < 0, I get a "DEBUG: Surface doesn't have a colorkey" in my debug logs.
(that wasn't the case until recently because previously it just returned -1 without calling SetError())

That was very misleading so I would suggest not printing out errors when the user didn't ask. Instead, possibly a different flag/function to make SDL trace all the SetError()s.

What do you think?
Comment 1 L 2018-07-16 15:53:22 UTC
(In reply to beuc from comment #0)
> Hi,
> 
> I see that when using SDL_LOG_PRIORITY_DEBUG, SDL_SetError() not only sets
> the current error but also prints it out.
> This sounds like a good idea at first, but in practice I get flooded by
> errors that I specifically handled in my code.
> For instance, whenever I query SDL_GetColorKey, even when I handle the case
> when the result is < 0, I get a "DEBUG: Surface doesn't have a colorkey" in
> my debug logs.
> (that wasn't the case until recently because previously it just returned -1
> without calling SetError())
> 

This is what the DEBUG category is for, debugging, it would be useless if it didn't print all the errors that happened. 

> That was very misleading so I would suggest not printing out errors when the
> user didn't ask. Instead, possibly a different flag/function to make SDL
> trace all the SetError()s.

By default none of these flags are on, so the user MUST be asking for it to be printed. Alternatively you could use GetError() after a function that might do a SetError() (And that is the proper way using SDL imo)
Comment 2 beuc 2018-07-16 16:21:34 UTC
Hi,

I probably didn't explain the use case properly:

- Context: my game uses the SDL_Log function with various log levels to trace errors. There is a game setting to set the log level to "debug" and get legitimate game errors while developing the game engine or working on an extension.

- When there is an error, SDL sets the error with SDL_SetError. Depending on the situation, my game queries SDL_GetError and prints it out (with the appropriate log level), or deal directly with the error and do not print it out.
E.g.: when calling SDL_GetColorKey, if there's no color key in the picture, then the game runs an alternate true-color processing, and nothing is printed.

- Now when the log is set to debug, SDL will print out every SetError, including the ones for errors/warnings that my game handles. This means the log is cluttered with both non-handled and handled errors.

Summary: the log level needs to trigger printing errors when SDL (or the game) actually prints errors, not when SDL merely sets the error message for later use (SDL_Log vs. SDL_SetError).

(btw, are you from the SDL team?)
Comment 3 L 2018-07-16 16:40:21 UTC
(In reply to beuc from comment #2)
> Summary: the log level needs to trigger printing errors when SDL (or the
> game) actually prints errors, not when SDL merely sets the error message for
> later use (SDL_Log vs. SDL_SetError).

But the log level actually does that, the thing is there is a SDL_LogDebug in the SetError function. You could try using a custom category, https://wiki.libsdl.org/SDL_LOG_CATEGORY#Remarks, for your engine/game specific debug logs in conjunction with SDL_logMessage().

> (btw, are you from the SDL team?)

No, I am not.
Comment 4 beuc 2018-07-16 16:46:16 UTC
I know there is a LogError call in SetError and that's basically what this bug is about.

If there's a real error in SDL I want to know about it, so filtering out SDL errors entirely is inadequate.

I issued this bug to discuss the issue with the SDL developers, I am not interested in explaining the issue to other users or getting support, there's a mailing list for that.