Re: [SDLmm-general] back in action

[Martin B. <bi...@as...>]

On Wed, 13 Apr 2005 11:11:58 -0700, David Hedbor wrote:


>I will now add the negative effects of exceptions.
>
>1) It complicates memory handling. I.e if you have code such as this:
>
>void myfunc() {
>  Type *data = new Type();
>  Type->do_something();
>  delete data;
>}

Then you have bad application code which you should fix, and not blame
SDLmm for it :->
Since exceptions are the standard C++ mechanism for reporting errors
and even the standard library uses them, you should write exception
safe code anyway, regardless if SDLmm uses it or not.


>I do_something throws an error which is recovered properly by the
>method calling myfunc, we now have leaked a reference to Type. Often
>this can be mostly fixed by using some sort of automatic or reference
>counted pointer object, but it's still a potental issue. 

But the goal of SDLmm is to provide a C++ abstraction of the SDL
functions. We shouldn't design the library around potential programs
that for whatever reason don't use the C++ mechanisms for automatic
memory management. If someone really wants to go the messy C way, he
can call SDL directly. 


>
>2) Even if you always correctly catch errors (you expect) when you
>   need to delete objects or handle the error, an unexpected exception
>   could still result in leaks since you for whatever reason didn't
>   handle it (sloppy programming or lack of knowledge of possible
>   exceptions). 

Ok, but an unexpected error return is far worse!
An unexpected exception passes through several layours of the
application until it is handled and the application can safely recover
or cleanly exit.
An unexpected error return goes totally unnoticed and the application
either gets stuck or crashes without you having any chance to recover
or even get an idea what the hell happened.


>3) Exceptions are best used for exceptional errors. I.e errors that
>   you cannot recover from. Using exceptions is slower than using
>   normal error handling and does complicate coding in the case it's
>   simply a warning or recoverable error.

I totally agree there. Exceptions are a mechanism to report and handle
bad errors. They are not intended to replace return results.

So we should perhaps go into detail and ask: which occasion are in
SDLmm where an exception might be thrown? 

In my opinion, all File I/O errors should be handled through
exceptions. Failed memory allocations as well (the new operator already
does this, but SDL uses malloc...). 



Regards,
   Martin