Request: Exceptionhandling?

[Haikarainen]

Why not create a sf::Exception to make SFML-usage much more flexible and easier to debug?

Take sf::Image for example, if you try to load an image that doesn't exist to it using sf::Image::LoadFromFile();, all it does is print "Error: File blablabla". It should throw an exception instead, so you can handle your errors appropriate to your actual project.

Like if you have a custom error-log-management, you could do this:

Code: [Select]


try{
sf::Image Bleh;
Bleh.LoadFromFile("./data/bleh.jph");

sf::Image Bleh2;
Bleh.LoadFromFile("./data/bleh2.jph");
}catch(sf::Exception &e){
myErrorManager << e;
}


instead of:

Code: [Select]


sf::Image Bleh;
if(!Bleh.LoadFromFile("./data/bleh.jph")){
MyErrorManager << "Couldn't load bleh from bleh.jph, this error is hardcoded and not very flexible.";
}



sf::Image Bleh2;
if(!Bleh2.LoadFromFile("./data/bleh2.jph")){
MyErrorManager << "Couldn't load bleh2 from other file bleh2.jph, this error is hardcoded and not very flexible.";
}

I was gonna post this as an issue/feature/request on the bugtracker, but didn't know how to approach that since i never used something like that before

[Laurent]

Exceptions don't work well with shared libraries, that's why SFML doesn't use them. And they would be hard to translate to other languages such as C.

[Haikarainen]

Exceptions don't work well with shared libraries, that's why SFML doesn't use them. And they would be hard to translate to other languages such as C.

Excuse my stupidity, but why wont they work well with shared libraries? You wouldn't have to translate them to other languages, just keep them to the most supported ones

If you ask me SFML would get alot cleaner, much more professional appeal etc if you'd implement exceptions.

[Laurent]

Excuse my stupidity, but why wont they work well with shared libraries?

It's tricky to get exceptions that can cross shared libraries boundaries. You can read a lot about it on the internet

You wouldn't have to translate them to other languages, just keep them to the most supported ones

I need to report errors in bindings, so I have to translate exceptions to something else that the target language supports

If you ask me SFML would get alot cleaner, much more professional appeal etc if you'd implement exceptions.

I agree

[Nexus]

Wasn't a reason not to implement exceptions that these errors are not considered fatal? That is, when an image can't be loaded, just show a white sprite instead of terminating the application?

Anyway, one can easily encapsulate the SFML functions and provide exceptions on top of them. That's what I do in the Resources module of my library, by the way.

[Laurent]

Wasn't a reason not to implement exceptions that these errors are not considered fatal? That is, when an image can't be loaded, just show a white sprite instead of terminating the application?

It was a reason. But after realizing that error handling is currently a total mess in SFML, I think that exceptions would make things a lot cleaner and safer.

[Groogy]

Well I hope it doesn't come as else I will have to remake rbSFML I think.

Though a better way to handle errors is not bad actually.

[Ceylo]

Maybe a way to enable/disable exceptions? So that bindings can still work with the current implementation, and those who want to use exceptions do something like sf::Exception::SetEnabled(true).

[Laurent]

Maybe a way to enable/disable exceptions?

It's not just a technical detail, it means a complete redesign of functions -- especially removing error codes from return types, and possibly making something useful of them.

[Ceylo]

I wouldn't change anything as for the return codes, not to break current projects and bindings. But just throw exceptions, if enabled, where it should be thrown.

That way, you have exception support without breaking anything.

[Laurent]

It doesn't make sense to have return codes together with exceptions...

[Hiura]

A very (very!) long time ago I asked the same question. http://www.sfml-dev.org/forum-fr/viewtopic.php?p=3522&highlight=exception#3522

At that time you convinced me with your arguments; will these arguments convince you today too ?  

[Laurent]

No

These arguments are still valid, but there are also many drawbacks that I didn't see at this time.

[Lee R]

I would suggest following the Boost.Filesystem approach to the dual exception/error-code interface problem.

Pseudo-code example:

Code: [Select]


namespace sf
{
    class ErrorCode
    {
        // impl..
    };
    class Exception
    {
        // impl...
    };

    //...

    void Devil::SetNumber( int param )
    {
        ErrorCode ec;
        SetNumber( param, ec );

        if ( ec )
        {
            throw Exception( ec );
        }
    }

    void Devil::SetNumber( int param, ErrorCode& ec )
    {
        if ( param != 666 )
        {
            ec = ErrorCode( EvilError );
            return;
        }
       
        m_Number = param;
    }
}   // namespace sf


[Laurent]

How does that solve the problem of exceptions across shared libraries boudaries?