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


More information about the vlc-devel mailing list