On 10/08/11 03:56, Michael Sweet wrote:
On Aug 9, 2011, at 1:39 AM, Ben Stott wrote:
...
(depending on how things go), if the RAII graphics lock (fltk::GSave,
currently) is unable to save the graphics state through the inability
to acquire or init. resources, an exception could be thrown to inform
the user that anything that happens from that point in the code is
going to hell in a handbasket.
How does throwing an exception help here - more than likely the app
will not be written to catch the exception (you'd need to wrap all
drawing in a try/catch block) and in the end you'll just end up with a
crashed app and lost data. OTOH, overflowing a matrix stack will just
result in some strange drawing, which is visible to the user and
developer but allows the user a chance to save their data.
Well sure, but there's also the possibility that the app hasn't been
written to catch a return error code too. My example was a tad moot in
that if GSave throws std::bad_alloc then the program is probably going
to end up having std::terminate() called on it (as nobody's going to
catch the allocation error). My point was more if GSave fails to
allocate its resources, the user's (original) data will have been
corrupted by the subsequent calls to draw() and make_current(). There's
nothing the user can do from there, and the picture could still
theoretically be coherent (assuming FLTK is built with -fno-exceptions).
They've just lost all their _initial_ data.
I do agree that exceptions shouldn't be added for things like buffer
overruns - our own code should be bug free like that, and we shouldn't
be providing an exception set specifically for developers of FLTK
applications.
...
> I see Ben says "They're portable (except perhaps to some really obscure
> embedded systems)" - I guess he means me!
I'd be surprised if most of these, nowadays, didn't support
exceptions. Given the push towards an attempt at standard-compilance
(and even pre-empting the c++0x standard) by most major compiler
vendors, I don't see why embedded system compilers would be *that*
much different....
Doing exceptions properly requires a LOT of overhead in the compiler
and runtime, and there exist today threading implementations which are
not safe to use with C++ exceptions, and not on obscure platforms,
either - throwing an exceptions from a dispatch thread (block) on Mac
OS X will do an excellent job of crashing your program, and blocks are
literally used *everywhere* in the system libraries now.
The overhead is relatively minimal if the exception isn't thrown - in
fact, if the exception isn't thrown it's more likely than not that the
overhead will be less than checking a return value more once. OTOH, a
thrown exception the overhead balloons out - but I'd argue if something
has gone wrong enough for an exception to be thrown, you can probably
justify the overhead.
However, I didn't know that about Macs - I was under the impression that
an exception occurring in a thread, blocking or not, would be held by
the same thread and at worst force a return of the thread if it weren't
handled?
Ben
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
