[vlc-devel] [Patches] Dash: mostly cosmetics

[Hugo Beauzée-Luyssen]

On Thu, Dec 1, 2011 at 7:34 AM, Tobias Güntner <fatbull at web.de> wrote:
> 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.
>

That's exactly what I'm trying to do. However I guess your point here
is STL is "our" code, while Qt is not. However the point stays, to me.

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

Indeed. We should check for bad_allow, bad_cast if we use references,
bad_typeid and ios_base::failure.
Saying that I've never encountered a code catching these exceptions
would be falacious, but true nevertheless.

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

I'm not saying we should get read of the STL exceptions, just most of
those in Dash, that are useless most of the time.

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

Again, I'm fine (and don't have much choice) with STL exceptions.

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

Let's take a code sample :

Representation.cpp :

SegmentInfo*        Representation::getSegmentInfo          () //...
{
    if(this->segmentInfo == NULL)
        throw ElementNotPresentException();

    return this->trickModeType;
}

BasicCMManager.cpp:

try
    {
        SegmentInfo* info = rep->getSegmentInfo();
        //....
    }
    catch(ElementNotPresentException &e)
    {
        /*TODO Debug */
    }

The error is handled twice. One so we can raise, and one to catch the error.
It looks clearer to me just to return the pointer, regardless of it's
value, and check it just once.

Again, I'm not saying anything about STL's exceptions. They're not
handled for now anyway.

>
> Regards,
> Tobias
>

Regards,

-- 
Hugo Beauzée-Luyssen