Completion of error handling

[elfring]

Would you like to add more error handling for return values from functions like the following?

• fread ⇒ LoadSettings
• fprintf ⇒ SaveSettings

[ocornut]

Yes. This part of the code (.ini saving/loading) was tackled in and isn't very robust. Will have a look (or feel free to submit a patch).

[elfring]

Are you interested to apply aspect-oriented software development?
How do you think about to encapsulate error detection and corresponding exception handling as a reusable aspect in your software?

[ocornut]

About the initial request. I have checked both LoadSettings and SaveSettings and haven't found a spot where additional meaningful error handling could be added. The return value to fread() is being used. In the unlikely case that fprintf() fails the following code can proceed happily.

Not interested in any change that would make the library less portable or carry more dependencies. Exceptions are disabled in many environment (embedded systems or game developpers typically disable exceptions in their compilers) and not a reasonable way of handling errors imho.

[elfring]

• How do you think about to change the return type of functions like "LoadSettings" and "SaveSettings" to "int"?
• Do you care if the passed data were completely written?
• Would you like to check for failed memory allocations?

[ocornut]

• Not needed
• No because the .ini file only saves window size/position as a commodity
• Possibly need to check for them more thoroughly / but effectively they don't happen or recovery is not meaningful. ImGui is engineered for adhoc debug apps.

[elfring]

• I Imagine that it will be occasionally useful to call the function "ferror".
• I guess that it would also be nice to handle an exception like "std::bad_alloc". How do you think about to add "try and catch" statements in the functions so that their implementations can safely be called by other C functions?

[ocornut]

You've been ignoring our other discussions so I am now assuming you are a bot.

[elfring]

There are a few different opinions around the affected error handling.
To which discussions would you like to refer to?

[ocornut]

Not using exceptions.

[elfring]

By which compiler parameters do you switch off the support for C++ exceptions here?
Is this an interesting implementation detail for your software portability?

[ocornut]

I don't recall the exact parameters. Many embedded and console developers don't allow exceptions because they add extra overhead which can't be afforded.