Re: [SDLmm-general] back in action

[David H. <da...@he...>]

"Martin Bickel" <bi...@as...> writes:

> 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.

Exceptions are optional (-fno-exceptions). And yes, the above is the
error of the code but it does show why exceptions aren't all perfect
for error handling. Error handling that makes it easier to get memory
leaks could be bad if used too much.

>>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. 

Automatic memory handling that's useful is something you need to
implement in the application layer. My main point is that it's really
really easy to make exceptions optional, enabled by default or
not. I would go as far as suggesting a run-time flag to disable the
use of exceptions. That way an app built on return codes will work
with a library that has exception handling turned on. It will be
mostly a free operation with little addtional code. No need to break
backwards compatibility when it's so easy to maintain it.

>>
>>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.

That pretty much depends on the case. It's easy to "hide" the fact
that something might thrown an exception (java is much better here
since you have to declare that a function can throw an exception
where in C++ this isn't the case). With return codes, you either get
one or you don't and you can see on the function whether or not it
returns something. Sure not handling the return code can have equally
bad results.

>>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.

I would go as far as saying non-recoverable errors primarily. 

> 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...). 

As far as I know, you can't easily determine that an error in SDL
occured due to failed memory allocation. You get "-1" return code and
a textual representation of the error, not an "errno" type error
code. How do you know if it's a memory related error? :)


-- 
[ Below is a random fortune, which is unrelated to the above message. ]
All the troubles you have will pass away very quickly.