The Exception to the C# Rules

Brady Kelly

        get
        {
            try
            {
                XTime.OL.UserObj myUserObj = (XTime.OL.UserObj)(HttpContext.Current.Session\["UserObj"\]);

                //If Session has not been created, go to catch
                if (myUserObj.USER\_CODEID == 0) { }

                return myUserObj;
            }
            catch
            {
                XTime.OL.UserObj myUserObj = new XTime.OL.UserObj();

                if (HttpContext.Current.Session != null)
                    HttpContext.Current.Session\["UserObj"\] = myUserObj;
                
                return myUserObj;
            }
        }

Go to catch is worse than using goto to go to catch.

Bernhard Hiller

Great idea! Instead of testing for myUserObj == null, he prefers to cause a NullReferenceException. Bad only, if it was some different kind of exception... Reminds me of the guy who reads beyond the end of a File, catches the exception (oh no, not "the", but any exception!) and in the catch block sets a flag that the end of the file was reached (and does not understand why that is bad coding...).

Lost User

Brady Kelly wrote:

Go to catch is worse than using goto to go to catch.

Yes, but unfortunately there are many "programmers" who liberally use exception handling mechanism to initialize object and to control code flow.

Keith Barrow

We have a lot of this where I work, I challenged it. Turns out the head honcho lives by this book[^], which is great, but Chapter 7 is all about how you define a normal flow and throw an exception if the normal flow is deviated from. Net result, a back-door goto mechanism implemented via try/catch/throw. It's the one chapter in the book that I disagree with (the rest is excellent) - the mechanism makes some sense if you have checked exceptions (as in Java - the language the book was written for) but then you are urged to switch the checked exceptions off. For some reason caking your calling code with try catch statements is better than caking it with checks on return value, and code-returning is the only alternative to the exception mechanism discussed.

PB 369,783 wrote:

I just find him very unlikeable, and I think the way he looks like a prettier version of his Mum is very disturbing.[^]

Bernhard Hiller

Ehm, did you realize the extra gem? if (myUserObj.USER_CODEID == 0) { } He provokes a NullReferenceException instead of checking the returned value myUserObj for null (also that book says: do not return null...). Of course, dealing with exceptions the Java style is very inconvenient for us .Net fans.

cpkilekofp

Shameel wrote:

Yes, but unfortunately there are many "programmers" who liberally use exception handling mechanism to initialize object and to control code flow.

I refer you to Sturgeon's Law: "90% of everything is crud, including this statement." This most definitely applies to programmers and to code.

"Seize the day" - Horace "It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover