Re: [SDLmm-general] back in action

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

Erich Herz <er...@gm...> writes:

> Hey everyone,
>
> I'm in process of cranking out a crappy gaim plugin, but I am hoping
> to start working on SDLmm really soon.  I know you are eager to see
> any work at all, since it's been 4 years since the last commit :P 
> This post is mainly to put things on the table for discussion.
>
> Now David has said that he has specifically left exceptions out of the
> library... I understand that a project goal is to stay as close to SDL
> as possible, which means, of course, using return values for error
> checking.  As much as I think this goal makes it easier on the
> programmer used to writing in SDL, I think that this attitude
> inherently means that some of the advantages of C++ are going to be
> lost (exception handling would be one, however small).  I'm of the
> opinion that, with some degree of restraint, perhaps this goal should
> be stretched a bit to allow for further development / improvement and
> not just a stagnant project.  David had already outlined his intention
> of adding "additional features" to SDLmm, such as the sprite class,
> but I wonder if this attitude can't be applied to the current source.
>
> Anyway, here's my case for exception handling:
>
> 1) Exceptions offer a consistent way of handling errors.  We know that
> if an error occurs within the library, an exception will be thrown. 
> No need to check error values, check global error variables, pass
> references or pointers to objects containing this type of information,
> etc...

This is true.

>
> 2) Exceptions reduce the amount of code the user of the library has to
> write.  Instead of having something like:
> if (SDL_CreateSurface(...) == -1) {
>    /* error handling code */
> }
> and then having to rewrite the same construct again each time we call
> a function, we need only put the body of main inside a try block, and
> we can write code without having to _worry_ about error handling.
>
> Motto: "less code? yayyy!"

Also true.

> 3) Exceptions can hold additional information about the error, and not
> just an error code or something retrieved from a global variable.  I
> know this is an advantage, somehow... :)

Yes, this is true as well.


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;
}

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. If automatic
pointers aren't used, you would get code like (pseudocode example):

void myfunc() {
  Type *data = new Type();
  try { Type->do_something();}
  catch ExpectedError err { delete data; throw err; }
  delete data;
}

which really isn't an much improvement over:

bool myfunc() {
  Type *data = new Type();
  if(Type->do_something() != OK) 
  { delete data; return false; }
  delete data;
  return true;
}

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

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'm not saying no to exceptions entirely but I'd really want to keep
the "original" calling conventions there, perhaps with a define. Also
SDL already has an error reporting mechanism. Sure it's a global error
string, but it's there. I could definitely see an error object used
which at its creation queries the error string and is then
thrown. However from Java programming, where exceptions are used
exclusively for errors, I can tell by experience that exceptions
doesn't make programming easier (well C++ exceptions are somewhat
different but similar never the less).

> There's a good discussion about exceptions on this page, if you're interested:
> http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=77463
>
> Exceptions aside, before I actually DO anything, I want to read
> through the code thoroughly, and alongside reading, fixing it up a bit
> ... is there any coding convention being used for the project right
> now?

Err. Yes. Mine. :) Seriously, I typically write code like this:

void foo(int x, string y) {
  char *bar;
  int i;
  if(bar == NULL) {
    ...
  } else if(foo) {
    ...	 
  }
  switch(i) {
  case 10:
    hello;
  case 1:
    gazonk
  }
}

with 2 character indentation, tab being set to the "standard" 8
characters. Emacs uses tabs/spaces automatically for indentation
although I'm not against changing it to be purely spaces. Just don't
code with an app that uses 2 or 4 or whatever char / tab. I also
don't like code such as:

if(X) {
} else 
  if(Y) {
  } else
    if(x) {
    }
since it is rather unclear and space wasting compared to 

if(X) {
} else if(Y) {
} else if(x) {
}

I sometimes uses 

void foo()
{
}

for functions.

> Anyway, I'd like very much to hear peoples' feedback about exception
> handling.  Any additional concerns / requests / comments about the
> library, or what could be done better would make my job a lot easier.

Making it use either would be great:

bool Display:Init(..) {
  int success = SDL_Init(..) == 0;
#ifdef USE_EXCEPTIONS
  if(!success) {
    throw new SDLmm::Exception(ret);
  }
#endif
  return success;
}

That would be backwards and SDL compatible with optional C++
exception error handling.

I should say though that I haven't entirely stuck to SDL standard
return codes. I typically translate the response to a boolean (true ==
success, false == error) where possible (i.e where SDL only has one
error response). SDL typically uses -1 for ERROR, and 0 for OK. I like
'true' to be OK not ERROR. :)

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
You'll wish that you had done some of the hard things when they were easier
to do.