[SDL] "Text has zero width" isn't an error.

Mason Wheeler masonwheeler at yahoo.com
Wed Apr 8 13:22:23 PDT 2009


>----- Original Message ----

>From: Edward Cullen <screamingwithnosound at googlemail.com>
>Subject: Re: [SDL] "Text has zero width" isn't an error.
>
>I hate it when people slag off C++ exception mechanism, normally
>because they're coming from a 'I don't understand it, so I'm going to
>slag it off' perspective.
Nope.  I'm coming from a "I do understand it, and it's badly defective,
so I'm going to slag it off" perspective.  I love exception handling. I
use it all the time in Delphi, where it actually works well.  Problem is
that in C++, it doesn't.

Defect 1:  The point of exception handling is to enable your program
to recover gracefully from unexpected conditions instead of
crashing.  But since the C++ runtime doesn't catch runtime errors
(NPD, div by 0, etc.) and translate them to exceptions, it's a lot
less useful than it could be.

Defect 2: You can throw anything at all.  This makes no sense when
you can't *catch* anything that's not an object without using catch(...)

Defect 3: Not 100% sure on this one, but if there's any way for you to
examine whatever it is you caught with catch(...) and determine its
nature, I'm not aware of if.  This makes handling unanticipated
exceptions much less useful than it could be.

Defect 4: The point of exception handling is to enable your program
to recover gracefully from unexpected conditions instead of
crashing. (Yes, I said that before. I'm repeating it because it's
important and C++ gets this wrong in at least 2 different ways.)  But
If something goes wrong and an exception is raised while another
exception is currently active, the C++ runtime calls Terminate(),
which is basically the same as crashing.

Defect 5: Despite the fact that (most valid) exceptions are objects,
and objects can inherit from other objects in a heirarchy, you have
to jump through special hoops in order to throw and catch
exceptions polymorphically.

>Assertions and exceptions are for two different purposes. Assertions
>catch programming errors; assertions *should* be disabled in
>production code, as you *should* have soooo many of them, that leaving
>them on would cirpple the performance of your application.
Really? I've never needed to put that many assertions in any function.
I think the most I've seen is 4, and they're usually trivial things like
checking that a certain pointer is not null, with such a low performance
impact that it's perfectly safe to leave them in for production code.




More information about the SDL mailing list