Comment On Try... Catch-em-all

That's quite chilling. It also reminds me I've not yet bollocked whoever it was who left this little gem:

catch (NullPointerException e) {

     System.out.println("Null Pointer");

}

Try
Comment.Post ()
Catch ex As FristException
Throw
Catch ex As WoodenTableException
Throw
Catch ex As XMLException
Throw
Catch ex As FileNotFoundException
Throw
Catch ex As EmbeddedSystemException
Throw
// TODO: add more exceptions
End Try

No, no, no. It is the "Try...Juggle" pattern. Throw-Catch-Throw-Catch...

I bet they heard Try-Catch-End Try was "bad".

More is better.

The WTF is it doesnt handle FileNotFoundException. And it should also get the list of exceptions from an XML file. obviously.

If at first you don't succeed, try and try again.

public int convert(string str) {

 int nr;

 success = Int32.TryParse(out nr, str);

 if (success != true) {

  try { nr = Int32.Parse(str) }

  catch { throw }

  try { nr = Int32.Parse(str) }

  catch { throw }

 }

 return nr;

}

I would vote for introducing a new language function that would reexecute code that raised the error, but in a more 'forceful' way. Something like:

try {
//Mess up code here
} catch (Exception $e) {
// handle exception
} try_harder {
// execute again.
}

IndexOutOfRangeException! I choose you! *throws exception*
Use InnerException now!

It's better than "On Error Resume Next".

Oh we had an error? It's okay, keep going.

Arguably, this is simply an attempt to document which exceptions can be thrown. (Java even has "syntactic sugar" for this, the "throws ..." next to a method prototype, which states that the method either generates, or continues to throw, exceptions of various types rather than handling them itself.) So the only large WTF I see here is that it was done with redundant code rather than with a comment.

From the architect that forget that to pass around types like a whore they need to be strongly named so instead uses strings to dynamically load DAL types instead of the actual type. Yummy.

Oh, wait, you mean the empty try and catches. Sadly I think I know the guy that wrote this and which State system it comes from.

Captcha: Pecus ... sounds like a game 7th grade boys play with each other in the bathroom.

At least the dev didn't just catch the general exception.

Public Function GetDAO(ByVal typeName As String) As Object

    Try

        Return Activator.CreateInstance(System.Type.GetType(typeName, True, True))

    Catch ex As Exception

        Throw

    End Try

End Function

But if all you're going to do is throw it there's no point in catching. This isn't baseball.

LightStyx:

IndexOutOfRangeException! I choose you! *throws exception*
Use InnerException now!

Hahaha nice post.. reminded of my childhood watching pokemon!

Captcha: luptatum. maybe a new pokemon? now there's 7894798478974

It could be code generation. I could see where it would be handy to have code generated that included catches for the specific exceptions thrown by a given method. It looks like they're in the correct order as well.

It looks like auto-generated IDE boiler-plate to me.

Ahh, the "Try...Fail" pattern. Seen this one plenty of times.

Kyle Z.:

LightStyx:

IndexOutOfRangeException! I choose you! *throws exception*
Use InnerException now!

Hahaha nice post.. reminded of my childhood watching pokemon!

Captcha: luptatum. maybe a new pokemon? now there's 7894798478974

If you are young enough to have watched Pokemon in your childhood, you're too young to be worth listening to. Get off the Internet and go "text" or whatever it is you young people do these days. Come back when you were born earlier.

Don't think I haven't noticed you on my lawn, too.

(Also: TRWTF is Visual Basic, amiright?)

Botia:

It could be code generation. I could see where it would be handy to have code generated that included catches for the specific exceptions thrown by a given method. It looks like they're in the correct order as well.

Alex:

It looks like auto-generated IDE boiler-plate to me.

OK, so how exactly does that make it any better? So what if it's generated code, the point is that some idiot generated it then checked it in as-is. This is an excellent example of terrible coding practices, irrespective of whether the code was spit out by a generator or not.

Leo:

(Also: TRWTF is Visual Basic, amiright?)

Yup, because they same code in C# definitely wouldn't be a WTF!

ais523:

Arguably, this is simply an attempt to document which exceptions can be thrown. (Java even has "syntactic sugar" for this, the "throws ..." next to a method prototype, which states that the method either generates, or continues to throw, exceptions of various types rather than handling them itself.) So the only large WTF I see here is that it was done with redundant code rather than with a comment.

It's only "syntactic sugar" in C++. If you have a throws clause including a checked Exception (descendant of java.lang.Exception), any caller of the method must catch all declared Exceptions or declare themselves to throw the same Exception.

Oneway:

I would vote for introducing a new language function that would reexecute code that raised the error, but in a more 'forceful' way. Something like:

try {
//Mess up code here
} catch (Exception $e) {
// handle exception
} try_harder {
// execute again.
}

E.g. when deleting a file fails because of lacking permissions, the next try will delete it without checking permissions, and the 3rd attempt will format the disk.

Seems like a great feature -- not to mention its use for posting comments on TDWTF.

Botia:

It could be code generation. I could see where it would be handy to have code generated that included catches for the specific exceptions thrown by a given method. It looks like they're in the correct order as well.

It's not "handy" to catch all the exception types, it's "correct". You just ain't supposed to throw them back again... "aargh, quick get rid of it before someone notices!"

Zach:

At least the dev didn't just catch the general exception.

Public Function GetDAO(ByVal typeName As String) As Object

    Try

        Return Activator.CreateInstance(System.Type.GetType(typeName, True, True))

    Catch ex As Exception

        Throw

    End Try

End Function

But if all you're going to do is throw it there's no point in catching. This isn't baseball.

The stronger you try to grasp the DAO, the more it slips through your fingers.

Anonymous:

Botia:

It could be code generation. I could see where it would be handy to have code generated that included catches for the specific exceptions thrown by a given method. It looks like they're in the correct order as well.

Alex:

It looks like auto-generated IDE boiler-plate to me.

OK, so how exactly does that make it any better? So what if it's generated code, the point is that some idiot generated it then checked it in as-is. This is an excellent example of terrible coding practices, irrespective of whether the code was spit out by a generator or not.

Well, it's not like it's doing any harm and the next programmer who comes along and sees an exception coming from that piece of code can see exactly where to add code to deal with it.
I wouldn't exactly recommend it, but it's a pretty weak WTF.

Leo:

Kyle Z.:

LightStyx:

IndexOutOfRangeException! I choose you! *throws exception*
Use InnerException now!

Hahaha nice post.. reminded of my childhood watching pokemon!

Captcha: luptatum. maybe a new pokemon? now there's 7894798478974

If you are young enough to have watched Pokemon in your childhood, you're too young to be worth listening to. Get off the Internet and go "text" or whatever it is you young people do these days. Come back when you were born earlier.

Don't think I haven't noticed you on my lawn, too.

(Also: TRWTF is Visual Basic, amiright?)

You got be an frustrated elder Cobol-Programmer.

About your lawn, sorry. I was just fleeing from your daughter room.

FLAMEWAR! (that's what we do in our age today)

Oh, just kidding, man!

Steve The Cynic:

No, no, no. It is the "Try...Juggle" pattern. Throw-Catch-Throw-Catch...

Sir, you made my day. A million internets for you. A shame we can't vote for comments, this qualifies as the best one I've seen in this site.

Zach:

At least the dev didn't just catch the general exception.

Public Function GetDAO(ByVal typeName As String) As Object

    Try

        Return Activator.CreateInstance(System.Type.GetType(typeName, True, True))

    Catch ex As Exception

        Throw

    End Try

End Function

But if all you're going to do is throw it there's no point in catching. This isn't baseball.

Hot potato!

Management: All routines will handle all exceptions, period.

The Nerve:

Zach:

At least the dev didn't just catch the general exception.

Public Function GetDAO(ByVal typeName As String) As Object

    Try

        Return Activator.CreateInstance(System.Type.GetType(typeName, True, True))

    Catch ex As Exception

        Throw

    End Try

End Function

But if all you're going to do is throw it there's no point in catching. This isn't baseball.

Hot potato!

Relay race!

Good ole catch and release. That's the proper way to handle exceptions like these; want to make sure there is enough for everyone on the call stack.

Lyle:

Management: All routines will handle all exceptions, without exception.

FTFY

I recognize that pattern. Its called "I need to debug an exception here but I don't want to handle it here, so I'll add in catches where I can set a breakpoint. Durr."

Not a horrible example of the pattern, mind you; it could be worse...

catch(InvalidOperationException ioe)
throw ioe;
catch(IOException ie)
throw ie;
...

expert:

Botia:

It could be code generation. I could see where it would be handy to have code generated that included catches for the specific exceptions thrown by a given method. It looks like they're in the correct order as well.

It's not "handy" to catch all the exception types, it's "correct". You just ain't supposed to throw them back again... "aargh, quick get rid of it before someone notices!"

It's not "correct" to catch all exception types; it's correct to catch all exceptions you actually *handle*.

The Real WTF is that they didn't use BobX.

<xbobfuncdef name="GetDAO">

  <xbobtry>

    <xbobfuncreturn>

      <xbobcall func="Activator.CreateInstance">

    <xbobendfuncreturn>

    <xbobcatch type="ArgumentNullException">

      <xbobthrow>

    <xbobendcatch>

    ...

    <xbobcatch type="TypeLoadException">

      <xbobthrow>

    <xbobendcatch>

  <xbobendtry>

<xbobfuncenddef>

Leo:

Come back when you were born earlier.

Nice one Emmet.

I get it. The WTF is that they're returning a DAO as a generic object rather than an instance of some interface/base class, thus requiring a cast by the calling code. LOL!!!

This is almost as bad as making use of the Diaper Anti-Pattern, the source of many a wtf.

The Try-Catch-Gulp pattern would be something like this :

try {

// something something

}

catch (Exception e) {}

Here it's more of a Try-Catch-Barf pattern.

do || !do;

if (false) try {}

Eaten by a Grue:

This is almost as bad as making use of the Diaper Anti-Pattern, the source of many a wtf.

Mike Pirnat:

It's called a Diaper because it catches all the sh*t.

So then I think this would be the fighting monkey pattern.

If that code is auto-generated by something like a GUI builder, it may not be able to be touched if you want to keep on using the GUI builder. I've encountered plenty of code like that before.

Anon:

Anonymous:

Botia:

It could be code generation. I could see where it would be handy to have code generated that included catches for the specific exceptions thrown by a given method. It looks like they're in the correct order as well.

Alex:

It looks like auto-generated IDE boiler-plate to me.

OK, so how exactly does that make it any better? So what if it's generated code, the point is that some idiot generated it then checked it in as-is. This is an excellent example of terrible coding practices, irrespective of whether the code was spit out by a generator or not.

Well, it's not like it's doing any harm and the next programmer who comes along and sees an exception coming from that piece of code can see exactly where to add code to deal with it.
I wouldn't exactly recommend it, but it's a pretty weak WTF.

I don't see anything wrong with what you suggest. If the programmer in question expects that the code will be changed in future - very unlikely - by a bunch of monkeys - even more unlikely - so that this function starts throwing exceptions, he is wise to provide a structure for the monkeys to bodge together a fix which will at least be in a comprehensible place.

C'mom guys. This isn't a WTF at all. How else would you simultaneously showcase your proficiency at using reflection and catch all the exceptions you want to throw?

Richard:

If that code is auto-generated by something like a GUI builder, it may not be able to be touched if you want to keep on using the GUI builder. I've encountered plenty of code like that before.

So there's a tool that produces breakage which can't be fixed if you want to keep using the tool? Easy enough: don't use that tool. And, just for safety, find and kill the person who wrote it. Razing their city would be a nice touch, but is not strictly necessary, however.

Such a shame nobody used the naming to their advantage:

Try
Comment.Post ()
Catch up As FristException
Throw up
Catch up As WoodenTableException
Throw up
Catch up As XMLException
Throw up
...
End Try

public class FuedingMonkeys {

	public static void main(String[] args) {

		new FuedingMonkey().throwBackCrap(new Exception());

	}



	public throwBackCrap(Exception e) {

		try {

			catchCrap(e);

		} catch (Exception e) {

			throwBackCrap(e);

		}

	}



	public void catchCrap(Exception e) throws Exception {

		throw e;

	}

}

Leo:

Kyle Z.:

LightStyx:

IndexOutOfRangeException! I choose you! *throws exception*
Use InnerException now!

Hahaha nice post.. reminded of my childhood watching pokemon!

Captcha: luptatum. maybe a new pokemon? now there's 7894798478974

If you are young enough to have watched Pokemon in your childhood, you're too young to be worth listening to. Get off the Internet and go "text" or whatever it is you young people do these days. Come back when you were born earlier.
...

Nice!

Still, acording to Wikipedia, Pokemon came out in 96. If Kyle was 12 when he watched Pokemon, that would make him 26... maybe you're just getting old. ;)

Public Function SteveBallmer()

    Try

        for monkeyboy = 1 to 4

             Response.Write("Developers")

        next monkeyboy

    Catch Hell

        Throw Chair

    End Try

End Function

Sylver:

Leo:

Kyle Z.:

LightStyx:

IndexOutOfRangeException! I choose you! *throws exception*
Use InnerException now!

Hahaha nice post.. reminded of my childhood watching pokemon!

Captcha: luptatum. maybe a new pokemon? now there's 7894798478974

If you are young enough to have watched Pokemon in your childhood, you're too young to be worth listening to. Get off the Internet and go "text" or whatever it is you young people do these days. Come back when you were born earlier.
...

Nice!

Still, acording to Wikipedia, Pokemon came out in 96. If Kyle was 12 when he watched Pokemon, that would make him 26... maybe you're just getting old. ;)

And if you'd read more than the first sentence of the Wikipedia article, you'd have seen that the Game Boy game came out in Japan in 1996, didn't make it to the US until 1998. However, he said it reminded him of watching Pokemon, not playing, and the show didn't hit the US till 1999. So if he was 12 in 1999 (which might actually be too old to have watched the show) then he's 23, and wet behind the ears.

Oneway:

I would vote for introducing a new language function that would reexecute code that raised the error, but in a more 'forceful' way. Something like:

try {
//Mess up code here
} catch (Exception $e) {
// handle exception
} try_harder {
// execute again.
}

We call that 'finally'