Request: Exceptionhandling?

[gsaurus]

I wouldn't change anything as for the return codes, not to break current projects and bindings.

Remember SFML2 can break it's interface as much as it's needed until released, no restrictions here. Let Laurent change it as much as he feel needed, in the end it's going to be better for all of us  .
We use SFML2 and we always have stuff to change, but it's a price to pay for using a version that isn't stable yet.
Maybe the bindings shouldn't be worked until it comes more stable.

I didn't know about the problems with shared libs, thanks (I'll have to retrace my codex project ). So that's a real problem...

[Nexus]

As far as I know, the shared library problem arises mainly if different runtime libraries are linked together. But this is generally a bad idea in C++, because it comes with many restrictions (different heaps, duplicate global data, incompatible STL containers). Following this argumentation, SFML might not use std::string in its interfaces either.

If we couldn't use exceptions across shared libraries at all, that language feature would be close to useless. Many C++ libraries use exceptions without problems. But I see that exceptions are problematic for language bindings (already because languages like C don't support them).

[Lee R]

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

As presented it doesn't, and nor should it. You do realise that Boost.Filesystem is a compiled library? The "exception problem" really isn't that much of a problem, and as far as it is a problem, the solution is to let the user compile the library themselves when they need non-default compiler settings (again, just as Boost.Filesystem does).

That being said, you could of course sidestep the issue all together by using the technique I presented, but have the throwing version of the functions be defined, inline, in the header file.

[Laurent]

As far as I know, the shared library problem arises mainly if different runtime libraries are linked together

It's true.

But this is generally a bad idea in C++, because it comes with many restrictions (different heaps, duplicate global data, incompatible STL containers). Following this argumentation, SFML might not use std::string in its interfaces either.

SFML shouldn't use std::string, yes (that's the reason why debug/release, or vc2008/vc2010 libraries can't be mixed)

But I see that exceptions are problematic for language bindings (already because languages like C don't support them).

This is not a blocking point to me, I guess that I can still find a workaround.

Many C++ libraries use exceptions without problems.

Which ones?

I've tried to read as much as possible about this issue, and I could find two relevant things:
- everyone says "don't throw exceptions across libraries boundaries", but nobody really know why
- it should be safe if both libraries and executables are compiled with the same compiler with the same settings -- which is already mandatory with SFML since it uses the STL in its public interface

So I guess it would be worth giving it a try. But I'd hate changing everything and then realizing that it doesn't work well with some OS/compiler. Any idea?

[Nexus]

Which ones?

For example Boost, Poco, Ogre.

This is not a blocking point to me, I guess that I can still find a workaround.

In CSFML, you would have to use return codes or a global variable. I don't know how much you want the usage to differ in SFML and its bindings, but I would not try to emulate exceptions in C

Any idea?

Another question: Where in the library would you introduce exceptions?

There are maybe really some justified use cases for return codes (the "non-fatal cases"). Eventually, some people end up writing wrappers that catch exceptions and return bools

[Groogy]

but I would not try to emulate exceptions in C

You can think even Wikipedia have a C++ inspired example of it with both Try and Catch macros. Though it's not C-like so CSFML should not do it. Just wanted provide unnecessary facts ^^

[Lee R]

There are maybe really some justified use cases for return codes (the "non-fatal cases"). Eventually, some people end up writing wrappers that catch exceptions and return bools

Or you just use the dual exception/error-code technique presented earlier in this thread and everyone is happy, including binding authors. Note also that this technique is going to become standard practice in the next C++ version (using the already available std::error_code et al).

[Nexus]

Though it's not C-like so CSFML should not do it.

The problem is not only that exceptions don't exist as a language feature in C, rather that they don't fit the entire language paradigms. In C++, we have RAII to easily write exception-safe code. This is also an issue to consider in managed languages like C#, where no real RAII (apart from using and finally) exists.

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

Or you just use the dual exception/error-code technique presented earlier in this thread and everyone is happy, including binding authors.

Attempts to make everyone happy are the keystone of every bad design. I don't consider the duality a good practice to apply in general. An exception doesn't exist if it can be replaced by a bool flag in every case.

Just consider a constructor that might fail. An exception is a good way to abort it. On the other side, providing an additional error checking mechanism implies the existence of a zombie object state. We introduce again the disadvantages we wanted to avoid by using exceptions.

Note also that this technique is going to become standard practice in the next C++ version.

Can you explain this?

[gsaurus]

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

They don't    Exceptions thrown inside a thread can only be caught by that thread. As a curiosity, on codex I catch and store any exception from the stream threads and re-throw it later to the main thread.

[Lee R]

Attempts to make everyone happy are the keystone of every bad design. I don't consider the duality a good practice to apply in general. An exception doesn't exist if it can be replaced by a bool flag in every case.

Just consider a constructor that might fail. An exception is a good way to abort it. On the other side, providing an additional error checking mechanism implies the existence of a zombie object state. We introduce again the disadvantages we wanted to avoid by using exceptions.

I don't actually disagree with that, but there is a problem here, and Boost.Filesystem has a reasonable answer, or are you also suggesting that Boost.Filesystem is badly designed?

Note also that this technique is going to become standard practice in the next C++ version.

Can you explain this?

Sure.

The error handling facilities from Boost.System, used in both Boost.Filesystem and Boost.Asio to provide the exact interface we are discussing, have been incorporated into the C++11 FDIS. Both Boost.Filesystem and Boost.Asio are expected to the incorporated into the next C++ standard. Once they become standard, I would also expect to see more libraries use the same, already standardised, error handling facilities (i.e. both exceptions and error-codes).

[Nexus]

I don't actually disagree with that, but there is a problem here, and Boost.Filesystem has a reasonable answer, or are you also suggesting that Boost.Filesystem is badly designed?

I haven't worked with the error codes in Boost.Filesystem yet, so I can't really judge it. How do they solve the problem of failing constructors? Anyway, I wouldn't take good design for granted just because it is Boost

Also take into account that SFML has other aims and another target group than Boost, for example it tries to be beginner-friendly and to have a clean API without much redundance, while Boost libraries often intend to be as generic and configurable as possible.

By the way, thanks for the explanation, I didn't know about the integration of error codes into C++11.

[Lee R]

I haven't worked with the error codes in Boost.Filesystem yet, so I can't really judge it. How do they solve the problem of failing constructors?.

I just had a look through its source, and in fact they don't. For some reason the documentation doesn't have an exception specification on the 'path' constructor, but it can throw if character conversion fails.

Just to reiterate, I don't disagree that exceptions are the One True Way to report errors from constructors, except when they're not: a type that has a legitimate intermediate state, or where failure is expected to occur during normal execution. Examples would include std::iostream construction, where opening the file may fail, or std::shared_ptr being constructed from a null pointer.

Also take into account that SFML has other aims and another target group than Boost, for example it tries to be beginner-friendly and to have a clean API without much redundance, while Boost libraries often intend to be as generic and configurable as possible.

Error codes are hardly rocket science, and they will have to learn them sooner or later anyway, since they are soon to be standardised.

By the way, thanks for the explanation, I didn't know about the integration of error codes into C++11.

You're quite welcome.

And in all this, nobody thought to mention that in fact SFML already uses exceptions. sf::Shape::AddPoint, for instance, will throw an std::bad_alloc exception on memory exhaustion.

[Laurent]

I've read a lot about the next C++ standard and yet I've never seen anything about error codes. Do you know any good article about this?

[Lee R]

Unfortunately not. There was a series written by one of the library's authors, but it seems his site is currently down.

There are various links to documentation available, though:
VC2010: http://msdn.microsoft.com/en-us/library/ee372183.aspx
Boost.System (the library's original seed): http://www.boost.org/doc/libs/1_46_1/libs/system/doc/index.html

[Laurent]

Thanks.