Catch{}//nothing to do here.



  • Yet another from the forum software...

            public void Track()
            {
                StringCollection links = GetLinks(body);
                foreach(string externalUrl in links)
                {
                    try
                    {
                       
                        string pageText = CSRequest.GetPageText(externalUrl,referral);
                        if(pageText != null)
                            TryToPing(pageText,externalUrl);
                    }
                    catch{}//nothing to do here.
                }

            }



  • What's the F here? There can be legitimate reasons to catch exceptions, especially at a high level where you don't want to break some behaviour in the caller. Suppose the caller changes the state of some object after this function returns, and wouldn't do so if the exception didn't get caught (that might have several reasons, e.g. this function being a call-back function). Then an exception could cause really nasty effects.

    Of course, the comment should have said so, but that's another story. If we're going "WTF?" every time we see an inadequate comment, we could take a role in The Big Lebowsky...



  • @TGV said:

    What's the F here? There can be legitimate reasons to catch exceptions, especially at a high level where you don't want to break some behaviour in the caller.


    1) Engineering was created so you don't "break" the beahaviour of some other part of your code. If you are using and empty catch to supress some exception, well, congratulations! I'm going to start to use Try/Catch to control the flow of my code, and achieve error-free procedures. See? No error is shown!
    2) If you have downloaded the source code, and took the time to read it, you would notice that this Try/Empty Catch is common use on their code! It's spreaded over several files.

    Now, that's what I call good design.



  • @TGV said:

    What's the F here? There can be legitimate reasons to catch exceptions, especially at a high level where you don't want to break some behaviour in the caller. Suppose the caller changes the state of some object after this function returns, and wouldn't do so if the exception didn't get caught (that might have several reasons, e.g. this function being a call-back function). Then an exception could cause really nasty effects.

    Of course, the comment should have said so, but that's another story. If we're going "WTF?" every time we see an inadequate comment, we could take a role in The Big Lebowsky...

    Like Sav said, they've taken it to the level of design pattern. Don't forget, they're in control of the whole source, it's not like some nameless third party added wtf throws into their functions; Telligent themselves did it, and then proceeded to simply ignore and override their own design. Although the number of functions they have that return any failure by throwing is pretty sad.



  • I vote they change the company's name to Brillant Systems [8-)]



  • @Mike R said:

    I vote they change the company's name to Brillant Systems [8-)]




    Nnngh.. Wrong emoticon.. [8-|]


Log in to reply