Comment On Inexception

Each exception thrown by our application must be caught handled

That's why all my code starts by defining a catch handle.

Hey we do that in our code! Except we use a construct called a "while loop" to get all the inner exceptions. I dunno, maybe this way is more enterprise-y?

Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???

OK, I'm not familiar with this construct... are there always that many inner exceptions?

In my experience, you never really need to dig more than a level or two down. To have that many nested levels means that you're being super Enterprise-y.

If you dig deep enough in the exception stack, you end in Limbo.

TRWTF is the empty catch block. What if the call to MessageBox.Show() fails? (maybe because of the too much nesting :-) )

Sam:

Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???

MessageBox.Show(WhileLoop.Message || Recursion.Message);

Well, TRWTF is this method of catching exceptions, but if you really must...

catch (Exception ex)

{

    MessageBox.Show(ex.Message);

    while (ex.InnerException != null)

    {

        ex = ex.InnerException;

        MessageBox.Show(ex.Message);

    }

}

The original version did use a loop. But, after profiling their application, they determined that the loop was a major performance bottleneck. What you see here is the result of their senior developer's optimization - he unrolled the loop.

Cool! I'm gonna throw such an exception then:

ex.InnerException = ex;

C'mon, this is just plain stupid... This can't exist, it's only the result of someone's imagination.

[quote user="LazerFX"]Well, TRWTF is this method of catching exceptions, but if you really must...

catch (Exception ex)

{

    MessageBox.Show(ex.Message);

    while (ex.InnerException != null)

    {

        ex = ex.InnerException;

        MessageBox.Show(ex.Message);

    }

}

[/quote]

... must... refactor...

catch (Exception ex)

{

    while (ex != null)

    {

        MessageBox.Show(ex.Message);

        ex = ex.InnerException;

    }

}

[/quote]

public class FuckYouException : Exception

{

    public FuckYouException() : base("Yeah well fuck you too!")

    {

    }



    public override Exception InnerExecption

    {

        get { return this; }

    }

}

keigezellig:

TRWTF is the empty catch block. What if the call to MessageBox.Show() fails? (maybe because of the too much nesting :-) )

N'ah it's there in case one of the InnerException's isn't there, resulting in a NullReferenceException when trying to get it's .Message property. After all, why would you check for null when you can just catch all exceptions? And why would MessageBox.Show() ever throw an exception?

I'd call it the Inception...

El Fredo:

If you dig deep enough in the exception stack, you end in Limbo.

He wanted to go deeper. Like a Limbo within a Limbo.

Would just like to point out the very useful GetBaseException() method :)

Like all great exception reporters, he discarded the stack trace and only showed the message.

Thumbs Up Man!

Exceptionally bad code can be found everywhere and this code is no exception!

If we go deep enough, perhaps we will not find an InnerException but throw a NullReferenceException, instead.

Every exception is a null reference exception.

Sam:

Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???

No, it doesn't - and don't call me Surely.

XXXXXX:

Like all great exception reporters, he discarded the stack trace and only showed the message.

Thumbs Up Man!

Yeah, this is sadly standard. We had an error handler that dumped the entire variable context (and since nearly everything is written in the global space, the emails were typically between 3-4MB), but no stack trace - after all, who needs a stack trace when 95% of your code is global? Our MSSQL error handler also routinely ate error messages, queries, etc, but that's more the fault of the MSSQL drivers for Linux...

Obviously TRWTF is indeed PHP.

Pock Suppet:

Sam:

Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???

No, it doesn't - and don't call me Surely.

XXXXXX:

Like all great exception reporters, he discarded the stack trace and only showed the message.

Thumbs Up Man!

Yeah, this is sadly standard. We had an error handler that dumped the entire variable context (and since nearly everything is written in the global space, the emails were typically between 3-4MB), but no stack trace - after all, who needs a stack trace when 95% of your code is global? Our MSSQL error handler also routinely ate error messages, queries, etc, but that's more the fault of the MSSQL drivers for Linux...

Obviously TRWTF is indeed PHP.

I bet you had handlers like this too:

catch(ex)
{
// throw the exception
throw ex;
}

MiffTheFox:

public class FuckYouException : Exception {
  public FuckYouException() : base("Yeah well fuck you too!") {
  }
  public override Exception InnerExecption {
    get { return this; }
  }
}

It's InnerExceptions all the way down!

I'm disappointed that nobody did an InnerFrist post.

It's exceptions, all the way down...

Tankster:

... must... refactor...

catch (Exception ex)

{

    while (ex != null)

    {

        MessageBox.Show(ex.Message);

        ex = ex.InnerException;

    }

}

Another refactor to prevent Kuli and MiffTheFox from exploding your stack...

catch (Exception ex)

{

    var visited = new HashSet<Exception>();

    while (ex != null && !visited.Contains(ex))

    {

        visited.Add(ex);



        MessageBox.Show(ex.Message);

        ex = ex.InnerException;

    }

}

Pock Suppet:

Sam:

Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???

No, it doesn't - and don't call me Surely.

XXXXXX:

Like all great exception reporters, he discarded the stack trace and only showed the message.

Thumbs Up Man!

Yeah, this is sadly standard. We had an error handler that dumped the entire variable context (and since nearly everything is written in the global space, the emails were typically between 3-4MB), but no stack trace - after all, who needs a stack trace when 95% of your code is global? Our MSSQL error handler also routinely ate error messages, queries, etc, but that's more the fault of the MSSQL drivers for Linux...

Obviously TRWTF is indeed PHP.

Insanity! Such error handling is unexceptable!

Tankster:

... must... refactor...

catch (Exception ex)

{

    while (ex != null)

    {

        MessageBox.Show(ex.Message);

        ex = ex.InnerException;

    }

}

Pff, the first execution of the while does an unnecessary check in yours.

catch (Exception ex) {

    do {

        MessageBox.Show(ex.Message);

    } while ((ex = ex.InnerException) != null);

}

<rant>
TRWTF is the absolutely horrible coding style.

CamelCase properties, class names, namespaces and sometimes event method names? What a great way to avoid ambiguities!
Not to mention the amazing space-saving brace placement.
</rant>

TRWTF is showing the final user (client?) an error which goes down to god knows where in the code and can be shit like:

throw new Exception("Passing null is for pussies");
throw new Exception("Shouldn't get here");
throw new Exception("The process with ID {gibberish} failed because the DB driver for {more gibberish} wasn't found.");

Not taking into account that non-technical users won't know WTF this means, it's not i18n, so you just added millions of people to your WTF. Oh! And now developers will have to think about nice error messages for their exceptions. And please, don't make your Exceptions i18n, this is EVEN MORE STUPID!

Next stop for this application will be Error'd

Dipshits.

Exception.ToString() already does this for you.

Throw this in LinqPad, then stop making fun of stupid people when you're just as fucking dumb.

new Exception("You",
new Exception("Are",
new Exception("Fucking",
new Exception("Stupid")))).ToString()

ReallyPeople:

Would just like to point out the very useful GetBaseException() method :)

Killjoy! That wipes out all the philosophical nuance by cutting straight to the answer.

"We demand rigidly defined areas of doubt and uncertainty!"

onitake:

<rant>
TRWTF is the absolutely horrible coding style.

CamelCase properties, class names, namespaces and sometimes event method names? What a great way to avoid ambiguities!
Not to mention the amazing space-saving brace placement.
</rant>

pretty sure that's all just standard .NET coding style.

Ugh. Exceptions. The out-of-band method of returning a sensible error state wrapped up in so-called "modern programming". Try-catch is rife with pointless issues. The only good thing try-catch can do is automatically restart a program that's crashed.

A more rational approach is to return a structure from all calls that contains a boolean to indicate success or failure of the call. If successful, the data portion contains the returned data. On failure, the data portion contains a human-readable error message, a machine-friendly error code, and optional data. The programmer is first required to unwrap the result of the call and test for success/failure, which should always be done, but no one does. If the return type enforces checking, the programmer will check it. try-catch doesn't enforce checking - programmers just let exceptions bubble up and they log the error(s) at best.

But the only languages that can handle that sort of return policy natively are weakly-typed languages (e.g. PHP can implement it via arrays). Strongly-typed languages, usually the sort that require an intermediate compilation stage, have a more difficult time (e.g. C++ could process the return data via macros but it would turn into a complete disaster pretty quickly).

Pock Suppet:

MSSQL drivers for Linux

I just threw up in my mouth a little.

This is worse than casting pearls before swine. This is more like sitting down to a fine dinner at a restaurant renowned for its excellence, and mixing in a little diarrhea with the salad dressing, just for added flavor.

I'll leave it to the reader to figure out which end of this interface is the fine food and which part is the diarrhea.

Sam:

Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???

I never write loops; and don't call me Shirley.

MessageBox.Show(ex.Message);

Why?

All the user is going to do is play whack-a-mole with your message box anyway.

To a user, a message box is a barrier between them and what they want to do. The sooner they can get rid of it the better.

They will commit suicide before they read it. Reading is painful. It might require thought. Expecting someone to think on the job is just inviting a lawsuit.

It has been demonstrated, even if the message box says in blinking red bold letters "Click OK to format your hard drive and wipe out all your data" they will still click OK.

That's why security warning pop-ups never work.

Each exception thrown by our application must be caught handled before the user sees it.

Isn't "caught handled" something that happens to teenage boys?

Spewin Coffee:

Ugh. Exceptions. The out-of-band method of returning a sensible error state wrapped up in so-called "modern programming". Try-catch is rife with pointless issues. The only good thing try-catch can do is automatically restart a program that's crashed.

A more rational approach is to return a structure from all calls that contains a boolean to indicate success or failure of the call. If successful, the data portion contains the returned data. On failure, the data portion contains a human-readable error message, a machine-friendly error code, and optional data. The programmer is first required to unwrap the result of the call and test for success/failure, which should always be done, but no one does. If the return type enforces checking, the programmer will check it. try-catch doesn't enforce checking - programmers just let exceptions bubble up and they log the error(s) at best.

But the only languages that can handle that sort of return policy natively are weakly-typed languages (e.g. PHP can implement it via arrays). Strongly-typed languages, usually the sort that require an intermediate compilation stage, have a more difficult time (e.g. C++ could process the return data via macros but it would turn into a complete disaster pretty quickly).

The issue with that is the "data" object will either not be strongly-typed (which, as you pointed out, makes the language a PHP-level WTF), or you would have to extend the return object class for each type that you use, which could lead to a maintenance nightmare. Either way, I'd rather have exceptions. Language developers can try to prevent stupid developers from messing up their own apps, but they will always win, so it's a futile attempt.

private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
ShowException(e.Exception);
}

private void ShowException (Exeption myEx)
{
if (myEx == null) return;
MessageBox.Show(myEx.Message);
ShowException(myEx.InnerException);
}

captcha : dolor (it's what i felt reading this WTF and my crappy recursion)

Spewin Coffee:

(e.g. C++ could process the return data via macros but it would turn into a complete disaster pretty quickly).

C++ could process the return data via an object that (in debug builds, duh) asserts in its destructor that the return value has been looked at.

It's hard to ensure that the check has actually done something useful, but it will show up in code reviews if you do something like this:

CheckedError<FlobState> retflob;



retflob = functionCall( stuff );



retflob.isSuccessful();

The method name .isSuccessful() is chosen carefully to look weird when it's called outside the context of an if() statement, so that it is easy to spot. (A lesson not learned by the Boost folks, who gave shared_ptr<T> a .get() method rather than the more accurate .sickeninglyBugInducingRawPointerRetrieval(). The only time I ever built a serious smart pointer object, my colleague and I were very purposeful in not giving it a quiet-named raw pointer retrieval method. Sure it had a method that could retrieve the raw pointer, but it was .operator ->(). Nobody much is going to call that explicitly, and anyone seeing such a call will squawk.)

No, you can't always remove the human element from your code validation process, but you can do things to make that element easier, like grabbing the GAU-8 from your back pocket and using it on anyone who suggests renamiing .sickeninglyBugInducingRawPointerRetrieval() to .get().

LazerFX:

Well, TRWTF is this method of catching exceptions, but if you really must...

catch (Exception ex)

{

    MessageBox.Show(ex.Message);

    while (ex.InnerException != null)

    {

        ex = ex.InnerException;

        MessageBox.Show(ex.Message);

    }

}

Now you've done it... Sometimes, the ex.InnerException won't be null, but a self-reference to ex, so you end up with a StackOverflow unless you add a check for ex == ex.InnerException

The WTFs that give my widescreen monitor a horizontal scrollbar are always the best.

Steve The Cynic:

C++ could process the return data via an object that (in debug builds, duh) asserts in its destructor that the return value has been looked at.

It's hard to ensure that the check has actually done something useful, but it will show up in code reviews if you do something like this:

CheckedError<FlobState> retflob;



retflob = functionCall( stuff );



retflob.isSuccessful();

The method name .isSuccessful() is chosen carefully to look weird when it's called outside the context of an if() statement, so that it is easy to spot. (A lesson not learned by the Boost folks, who gave shared_ptr<T> a .get() method rather than the more accurate .sickeninglyBugInducingRawPointerRetrieval(). The only time I ever built a serious smart pointer object, my colleague and I were very purposeful in not giving it a quiet-named raw pointer retrieval method. Sure it had a method that could retrieve the raw pointer, but it was .operator ->(). Nobody much is going to call that explicitly, and anyone seeing such a call will squawk.)

No, you can't always remove the human element from your code validation process, but you can do things to make that element easier, like grabbing the GAU-8 from your back pocket and using it on anyone who suggests renamiing .sickeninglyBugInducingRawPointerRetrieval() to .get().

I'm out of GAU-8 rounds from the last time I saw developers creating void functions with the prefix "Get", and non-void functions with the prefix "Load."

The real WTF is using anything other than Exception.ToString()

Who cares what the exception message is, normally it's wrong/misleading/empty anyway. What you need is a stack trace, which is what ToString generates for you.

At first I wondered what would happen if the inner-exception was null, then I noticed in the comments try-catch. Sure enough, it's wrapped in a try-catch.

...

I just don't know what to say now.

Captcha:
nimis - Several minis turned inside out.

chubertdev:

I'm out of GAU-8 rounds from the last time I saw developers creating void functions with the prefix "Get", and non-void functions with the prefix "Load."

public static Object XamlReader.Load(Stream stream)

http://msdn.microsoft.com/en-us/library/ms590388.aspx

Time to re'load'

TGV:

I'd call it the Inception...

THAT'S THE JOKE

Ralph:

Pock Suppet:

MSSQL drivers for Linux

I just threw up in my mouth a little.

This is worse than casting pearls before swine. This is more like sitting down to a fine dinner at a restaurant renowned for its excellence, and mixing in a little diarrhea with the salad dressing, just for added flavor.

I'll leave it to the reader to figure out which end of this interface is the fine food and which part is the diarrhea.

Perl?