Move error checking to the low-level bindings

[polarina]

The idea is to move SDLException and the associated error checks of SDL's functions' return values to the low-level bindings (SDL.Raw and Graphics.UI.SDL).

Advantages include:

• The user does not have to explicitly check the return value of almost every SDL function invocation.
• It is less error-prone as we can be more certain that we haven't left any needed error checks out in both the high-level bindings and other application code.

One disadvantage I have been able to conceive is if a user wants to completely ignore the error checking. I have, however, not yet been able to think of any circumstances where this is desirable.

Any comments?

[ocharles]

How are you going to respond to errors? The problem is that I see at least two perfectly valid routes:

1. Throw exceptions
2. Work under EitherT IO

It seems that if you want to do error checking this far down the abstraction hierarchy, you're going to force your opinion as to what is most preferable on a lot of people.

[ocharles]

Oh, there is also the problem of whether everything should be considered a fatal error. Just because I fail to change the state of something in SDL - should my entire game terminate?

[polarina]

@ekmett has suggested that it is possible to catch exceptions and ignore them should they ever be undesirable. There's also the possibility of adding unchecked variants, such as createWindow and createWindow'.

Currently, everything in the high-level bindings checks for errors and throws an exception, and would terminate your game if you or the user does something wacky if you don't catch them. I don't see how this is any different as far as that goes.

I've seen people, for the sake of simplicity of their test applications, completely ignore the return values from the low-level bindings and hoping they never encounter them. This would allow them to see why their program's not working.

[ocharles]

The difference with the high level bindings is that its OK for them to be opinionated. However if you choose to throw exceptions in the low level bindings, choosing to ignore them everywhere or provide an alternating API is costly. I'm OK with all of this, just wanted to provide another view On 7 Dec 2014 14:33, "Gabríel Arthúr Pétursson" [email protected] wrote:

@ekmett https://github.com/ekmett has suggested that it is possible to catch exceptions and ignore them should they ever be undesirable. There's also the possibility of adding unchecked variants, such as createWindow and createWindow'.

Currently, everything in the high-level bindings checks for errors and throws an exception, and would terminate your game if you or the user does something wacky if you don't catch them. I don't see how this is any different as far as that goes.

I've seen people, for the sake of simplicity of their test applications, completely ignore the return values from the low-level bindings and hoping they never encounter them. This would allow them to see why their program's not working.

— Reply to this email directly or view it on GitHub https://github.com/haskell-game/sdl2/issues/33#issuecomment-65939089.

[ekmett]

:+1: from me for making the change.

[ocharles]

@ekmett You mean (MonadThrow m, MonadIO m) => ... -> m () rather than MonadIO m => ... -> EitherT String m (), right?

[ekmett]

I'm definitely not looking for EitherT in the stack.

I'm fairly neutral between

(MonadThrow m, MonadIO m) => ... -> m ()

and

MonadIO m => ... -> m ()

and lifting the throw in the latter, which is what I do now, though.

All of the stock exceptions instances for the former and the latter are compatible.

[polarina]

I am going to go ahead with these changes. I am opting for using MonadThrow to throw exceptions.