Request: Exceptionhandling?

[Disch]

For SFSL, I was strongly considering taking the WinAPI approach to error handling.  Keep the simplistic true/false return, but provide more details about the error if needed via a GetLastError/SetLastError mechanism.

The last error could be stored in a sf::ThreadLocalPtr making it threadsafe.

Adding the possibility of throwing on failure is relatively easy with this setup, as well.  You could allow the user to specify boolean values to indicate whether or not they want it to throw on specific errors.  Then in SetLastError, if you set such an error, just throw it.


EDIT:

Another possibility is deriving classes from a common "Errorer" class which has its own Get/Set error functions.

[Oberon]

As a reminder: Reworking the error handling mechanism is better done before than after the release of SFML 2.

The problem with exceptions thrown across shared library boundaries, seems (according to the quick googling I just did )not to be a showstopper, as long as (a) SFML is not loaded with LoadLibrary or dlopen and (b) application and library are compiled/linked with the same compiler with the same version, which must be done anyway.
As Nexus mentioned it works well at least in Boost and other big libraries. The Boost Filesystem library, which is among the few boost libraries that need to be compiled (also as a shared library!) for example, makes extensive use of exceptions.

But if you absolutely do not want to use exceptions and keep the return codes, a GetLastError/SetLastError mechanism, like Disch proposed would still be a big improvement over the current stream-based system, which makes it very difficult to log the error messages to a file in a customized format (e.g. HTML), display them to the user (in a non-console application), translate them to exceptions yourself, or generally do anything useful with them.
Maybe you could also call a user defined callback, or raise a signal.

[Laurent]

It's definitely too late to switch to exceptions, SFML 2 is almost released. Let's discuss it again for SFML 3

I can add later a function to get the last error, since it doesn't break the public API.

[Groogy]

But still wasn't exception a "showstopper" for bindings since not all bindings support exceptions or are very incompatible with C++ exception code?

I am not against nor for exception, I like to see them be used where they fit which isn't as simple as you might think.

In the ruby bindings we use the stream based system to either raise exceptions or keep the original behaviour based on a configuration flag in the SFML module. Don't know but is something like that possible? Or might be stupid to actually have two different behaviours?

[Laurent]

But still wasn't exception a "showstopper" for bindings since not all bindings support exceptions or are very incompatible with C++ exception code?

Yep, I still don't know how to translate them to C.

[Oberon]

Yep, I still don't know how to translate them to C.

Just catch them and return error codes? e.g

Code: [Select]


try
{
    texture->This->LoadFromFile(filename, rect);
}
catch (Exception& e)
{
    //cleanup
   
    SetLastError(e.what().c_str());
    return NULL;
}

The C binding itself is in C++, so it can handle exceptions.

[formerBGIuser]

Well why not just have C-style error checking in SFML in 2.0 and then do exceptions for version 3?  You could use a Uint16 and have plenty of error codes to return, and then have an array of std::strings or const char * strings in SFML_system.h and just return those with a getError function that just spits that back when the user calls it?  My personal motivation is that I haven't been able to run any SFML 1.6 code on either of my computers for awhile (with MingW, MSVC++ is fine), even though I updated my graphics drivers and used mingw-with-gcc-4.4.  You could use the RenderWindow constructor to just set the values and then use an initter to actually make the attempt and then return an error code, that's how I see it. 

[Nexus]

In SFML 3, the C++11 standard library with its std::error_code could also serve as inspiration for an error-handling design.

[MorleyDev]

By the way, I don't know how well exceptions work across threads.

std and boost thread both catch any exceptions thrown in the thread, and then rethrow them when a join() is called. That's how they pass them to different threads. If it's not done by the code explicitly like that, I think it's undefined. It could just vanish into the abyss and the thread ends, or it could die and take the whole program with it. I'd hope it does the latter, but fear it'd do the former.

I don't know if SFML does something similar with sf::Thread. I try to use std::thread or boost::thread if that's not available (like on windows) with wrappers around boosts differences to bring them in line with the standard.

Personally I've always felt exceptions were for exceptional circumstances in C++, places where you very much want the whole program to be potentially aware of a critical error and all pre-tense of encapsulation to be broken. Places where the best thing for your program is probably to just kill itself as quickly and messily as possible. So for me they've always been for if things go wrong at a fundamental level, like running out of heap memory. Otherwise, avoid.

This has the downside of not being able to identify specific problems when multiple things can go wrong, but the afore-mentioned override method could work for that if you care (of course in an ideal world, each function would only have one possible error xD). Or maybe instead of a reference, take a pointer that defaults to null. If it's null, just fail. If not, store specifics in that which it points to. Perhaps uglier, but less writing at least xD

Just my 2 pence.

[Nexus]

The C++ 2011 standard provides std::exception_ptr, see this MSDN page for example.

[MorleyDev]

The C++ 2011 standard provides std::exception_ptr, see this MSDN page for example.

That's it! I was trying to think of the thing they added. I'm correct in that the join point is specifically when std::thread rethrows, yes? As I understand it still has to be done explicitly (as std::thread does), but it does at least make it easier...