Comment On Inexception

Exceptions are a great source of stress and suffering. Each exception thrown by our application must be caught handled before the user sees it. Failing to do disturbs the balance of our application. We can use a generic exception handler, but we never can be truly certain we’ve found the true exception. So often the Truth is hidden within an inner exception. It may also be hidden within that exception’s inner exception . [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Inexception

2013-02-21 08:04 • by Jerry (unregistered)
Each exception thrown by our application must be caught handled
That's why all my code starts by defining a catch handle.

Re: Inexception

2013-02-21 08:05 • by The_Assimilator
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?

Re: Inexception

2013-02-21 08:06 • by Sam (unregistered)
Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???

Re: Inexception

2013-02-21 08:07 • by snoofle
OK, I'm not familiar with this construct... are there always that many inner exceptions?

Re: Inexception

2013-02-21 08:08 • by Remy Porter
401747 in reply to 401746
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.

Re: Inexception

2013-02-21 08:09 • by El Fredo (unregistered)
If you dig deep enough in the exception stack, you end in Limbo.

Re: Inexception

2013-02-21 08:10 • by keigezellig
TRWTF is the empty catch block. What if the call to MessageBox.Show() fails? (maybe because of the too much nesting :-) )

Re: Inexception

2013-02-21 08:10 • by Tom (unregistered)
401750 in reply to 401745
Sam:
Shirley this calls for a loop. Or maybe even recursion? Or a loop?? Or recursion???
MessageBox.Show(WhileLoop.Message || Recursion.Message);

Re: Inexception

2013-02-21 08:11 • by LazerFX (unregistered)
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);
}
}

Re: Inexception

2013-02-21 08:16 • by Brian Friesen (unregistered)
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.

Re: Inexception

2013-02-21 08:19 • by Kuli (unregistered)
401755 in reply to 401751
Cool! I'm gonna throw such an exception then:

ex.InnerException = ex;

Re: Inexception

2013-02-21 08:20 • by Pista (unregistered)
C'mon, this is just plain stupid... This can't exist, it's only the result of someone's imagination.

Re: Inexception

2013-02-21 08:25 • by Tankster
401757 in reply to 401751
[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]

Re: Inexception

2013-02-21 08:25 • by MiffTheFox
401758 in reply to 401744

public class FuckYouException : Exception
{
public FuckYouException() : base("Yeah well fuck you too!")
{
}

public override Exception InnerExecption
{
get { return this; }
}
}

Re: Inexception

2013-02-21 08:28 • by JM (unregistered)
401759 in reply to 401749
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?

Re: Inexception

2013-02-21 08:41 • by TGV
I'd call it the Inception...

Re: Inexception

2013-02-21 08:43 • by Arvind (unregistered)
401761 in reply to 401748
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.

Re: Inexception

2013-02-21 08:45 • by ReallyPeople (unregistered)
Would just like to point out the very useful GetBaseException() method :)

Re: Inexception

2013-02-21 08:46 • by XXXXXX (unregistered)
Like all great exception reporters, he discarded the stack trace and only showed the message.

Thumbs Up Man!

Re: Inexception

2013-02-21 08:51 • by My Name (unregistered)
Exceptionally bad code can be found everywhere and this code is no exception!

Re: Inexception

2013-02-21 08:54 • by Andrew (unregistered)
If we go deep enough, perhaps we will not find an InnerException but throw a NullReferenceException, instead.

Re: Inexception

2013-02-21 08:55 • by Phil (unregistered)
Every exception is a null reference exception.

Re: Inexception

2013-02-21 09:06 • by Pock Suppet (unregistered)
401767 in reply to 401745
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.

Re: Inexception

2013-02-21 09:14 • by Bring Back TopCod3r (unregistered)
401768 in reply to 401767
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;
}

Re: Inexception

2013-02-21 09:16 • by ¯\(°_o)/¯ I DUNNO LOL (unregistered)
401769 in reply to 401758
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.

Re: Inexception

2013-02-21 09:17 • by Marc (unregistered)
It's exceptions, all the way down...

Re: Inexception

2013-02-21 09:17 • by lscharen
401771 in reply to 401757
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;
}
}

Re: Inexception

2013-02-21 09:23 • by Anonymous Paranoiac (unregistered)
401772 in reply to 401767
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!

Re: Inexception

2013-02-21 09:24 • by bkDJ
401773 in reply to 401757
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);
}

Re: Inexception

2013-02-21 09:30 • by onitake (unregistered)
<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>

Re: Inexception

2013-02-21 09:34 • by ubersoldat
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

Re: Inexception

2013-02-21 09:37 • by Will (unregistered)
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()

Re: Inexception

2013-02-21 09:40 • by dgvid
401777 in reply to 401762
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!"

Re: Inexception

2013-02-21 10:06 • by Anonymous Coward (unregistered)
401778 in reply to 401774
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.

Re: Inexception

2013-02-21 10:26 • by Spewin Coffee (unregistered)
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).

Re: Inexception

2013-02-21 10:27 • by Ralph (unregistered)
401782 in reply to 401767
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.

Re: Inexception

2013-02-21 10:35 • by DrPepper (unregistered)
401783 in reply to 401745
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.

Re: Inexception

2013-02-21 10:35 • by Walter (unregistered)
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.

Re: Inexception

2013-02-21 10:50 • by chubertdev
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?

Re: Inexception

2013-02-21 11:03 • by chubertdev
401786 in reply to 401781
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.

Re: Inexception

2013-02-21 11:09 • by Excelsior (unregistered)
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)

Re: Inexception

2013-02-21 11:14 • by Steve The Cynic
401788 in reply to 401781
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().

Re: Inexception

2013-02-21 11:15 • by Spits Coffee Through His Nose (unregistered)
401789 in reply to 401751
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

Re: Inexception

2013-02-21 11:26 • by Nexus (unregistered)
The WTFs that give my widescreen monitor a horizontal scrollbar are always the best.

Re: Inexception

2013-02-21 11:31 • by chubertdev
401791 in reply to 401788
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."

Re: Inexception

2013-02-21 11:34 • by Smouch (unregistered)
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.

Re: Inexception

2013-02-21 11:45 • by Valued Service (unregistered)
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.

Re: Inexception

2013-02-21 11:47 • by Valued Service (unregistered)
401794 in reply to 401791
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'

Re: Inexception

2013-02-21 11:57 • by operagost
401795 in reply to 401760
TGV:
I'd call it the Inception...

THAT'S THE JOKE

Re: Inexception

2013-02-21 11:59 • by operagost
401796 in reply to 401782
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?
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment