• SR (unregistered)

    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");
    }
  • fjf (unregistered)

    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

  • (cs)

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

  • (cs) in reply to SR

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

    More is better.

  • John (unregistered)

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

  • (cs)

    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;
    }
    
  • Oneway (unregistered)

    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. }

  • (cs)

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

  • Spivonious (unregistered)

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

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

  • (cs)

    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.

  • Ah yes (unregistered)

    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.

  • Zach (unregistered)

    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.

  • Kyle Z. (unregistered) in reply to LightStyx
    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

  • Botia (unregistered)

    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 (unregistered)

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

  • Bus Logic (unregistered)

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

  • Leo (unregistered) in reply to Kyle Z.
    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?)

  • Anonymous (unregistered) in reply to Alex
    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.
  • (cs) in reply to Leo
    Leo:
    (Also: TRWTF is Visual Basic, amiright?)

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

  • The Nerve (unregistered) in reply to ais523
    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.

  • fjf (unregistered) in reply to Oneway
    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.

  • expert (unregistered) in reply to Botia
    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!"
  • silent d (unregistered) in reply to Zach
    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.

  • Anon (unregistered) in reply to Anonymous
    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.

  • Kyle Z. (unregistered) in reply to Leo
    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!

  • Izhido (unregistered) in reply to Steve The Cynic
    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.

  • The Nerve (unregistered) in reply to silent d
    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!

  • Lyle (unregistered)

    Management: All routines will handle all exceptions, period.

  • The Nervous System (unregistered) in reply to The Nerve
    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!

  • (cs)

    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.

  • Denholm Reynholm (unregistered) in reply to Lyle
    Lyle:
    Management: All routines will handle all exceptions, without exception.

    FTFY

  • Will (unregistered)

    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; ...

  • The Real, Non-Random Steve (unregistered) in reply to expert
    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.

  • * (unregistered)

    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>
    
  • qbolec (unregistered) in reply to Leo
    Leo:
    Come back when you were born earlier.
    Nice one Emmet.
  • (cs)

    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!!!

  • Eaten by a Grue (unregistered)

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

  • Ethan Qix (unregistered)

    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.

  • (cs)

    do || !do;

    if (false) try {}

  • The Nerve (unregistered) in reply to Eaten by a Grue
    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.

  • Richard (unregistered)

    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.

  • (cs) in reply to Anon
    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.

  • (cs)

    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?

  • wtf (unregistered) in reply to Richard
    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.

  • Candy (unregistered)

    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

  • Fighting Monkey (unregistered)
    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;
    	}
    }
    
  • Sylver (unregistered) in reply to Leo
    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. ;)

  • (cs)
    Public Function SteveBallmer()
        Try
            for monkeyboy = 1 to 4
                 Response.Write("Developers")
            next monkeyboy
        Catch Hell
            Throw Chair
        End Try
    End Function
    
  • anon (unregistered) in reply to Sylver
    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.

  • send me the codez (unregistered) in reply to Oneway
    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'

Leave a comment on “Try... Catch-em-all”

Log In or post as a guest

Replying to comment #316447:

« Return to Article