[vlc-devel] [Patches] Dash: mostly cosmetics
Tobias Güntner
fatbull at web.de
Thu Dec 1 07:34:08 CET 2011
Am 30.11.2011 16:55, schrieb Hugo Beauzée-Luyssen:
> Well the argument stating that "you don't want to do this" is wrong to
> me. Otherwise we may want to rewrite Qt to catch those exceptions, for
> instance.
Sure, but we have to resolve VLC ticket #35 first. ;) Let's focus on
"our" code for now.
> However, yes, we should check for std::bac_alloc everywhere,
> or replacing new by new(nothrow) and check for NULL pointers.
Ah, I forgot about nothrow. ;) But it's not that simple, unfortunately.
new(nothrow) only applies to the allocation itself; it does not prevent
the constructor from throwing an exception (including bad_alloc).
> My point about exceptions here was : they are not required, and can be
> replaced by a (IMHO) cleaner solution, IE a proper return value.
My point is: STL containers rely on exceptions, thus replacing
exceptions with something else is not (easily) possible.
For example, could you rewrite DOMHelper::getElementByTagName without
exceptions? And would it really be "cleaner" in some way?
(Specifically, I am referring to the allocation of, insertions into, and
return of the elements vector. All those operations can throw. The calls
to at(i) should not be a problem, however.)
I think we agree that errors must be handled, but we disagree regarding
the error *reporting* mechanism. I look at it this way: Banning
exceptions is like shooting the proverbial messenger, just so that you
can deliver the bad news yourself. ;)
What we "gain" by this is that the compiler no longer takes care of
error reporting for us; we need to do it ourselves. I find that
extremely tedious and annoying. And since we cannot change the STL, we
*still* have to deal with its exceptions. IMHO this is a lot of trouble
for very little benefit, if any.
Regards,
Tobias
More information about the vlc-devel
mailing list