• (unregistered)

    Actually, catch(Exception e) does not catch everything that can be thrown...

  • (cs)

    So, the logic is as follows:

    1 Set the flag to true. 2 Do the work 3 Set the flag to false when the work has been done

    If any failure occurs during step 3, the work has succeeded, so silently swallow the exception.

  • (cs) in reply to

    :
    Actually, catch(Exception e) does not catch everything that can be thrown...

    It doesn't? That's new to me. I'd love to see an example.

    I still think this is a major wtf. Why on earth would you want to do it this way... me wonders...

  • (unregistered) in reply to Razzie

    Exception is a subclass of Throwable, so anything that is a Throwable but not an Exception can be thrown and won't be caught by catch(Exception e). In practice this is limited to subclasses of Error, which are not generally things one should catch anyway.

  • (cs) in reply to Razzie
    Razzie:

    [image]  wrote:
    Actually, catch(Exception e) does not catch everything that can be thrown...

    It doesn't? That's new to me. I'd love to see an example.

    I still think this is a major wtf. Why on earth would you want to do it this way... me wonders...

  • (cs) in reply to Scott

    Hmm, I wrote an example the first time.  I guess the system doesn't actually want people to quote other people.  Here it is again.  In asp.net:

    try
    {
        Response.Redirect("YourMomIsHot.html");
    }
    catch(Exception e)
    {
        //this never gets hit
    }

  • (cs) in reply to

    It wouldn't matter anyway.  If the catch lets one slip past, you'll continue the unwind and skip all the flag nonsense.

    My only thought is that this dude doesn't realize you can put a throw inside a catch block without making the computer catch fire  That doesn't explain why he checks the flag inside the catch block though....  Strange code...

    Maybe some messed up implementation of checked exceptions is forcing this monstrosity?

  • (cs) in reply to

    :
    Exception is a subclass of Throwable, so anything that is a Throwable but not an Exception can be thrown and won't be caught by catch(Exception e). In practice this is limited to subclasses of Error, which are not generally things one should catch anyway.

    True.

    But it's still a WTF since he's basically not trusting the catch to only fire when an Exception has been thrown - he tests the Boolean before executing any code within the catch block....

  • (cs)

    You can never be too sure.  He's just checking to see if it is REALLY REALLY an exception.

  • (cs) in reply to Spaceman Spiff

    Perhaps there was some code behind the setting of the flag to false where it didn't matter if an exception was thrown (like trying to send an email or something, who cares if that fails?). Still, I would personally put that in two separate try/catch constructions.

    The .Net code that's above here in the forum somewhere probably gives a 'Thread was being aborted' exception. This is not caught because it happens in the logic of the try/catch. Not sure if putting ANOTHER try/catch around it would help, cos chances are it would generate the same error. You can catch it though in the global.asax [:P]

    Drak

  • (unregistered) in reply to Scott
    Scott:
    Hmm, I wrote an example the first time.  I guess the system doesn't actually want people to quote other people.  Here it is again.  In asp.net:

    try
    {
        Response.Redirect("YourMomIsHot.html");
    }
    catch(Exception e)
    {
        //this never gets hit
    }


    can we please avoid another discussion of Request.Redirect? We've been over this one a few times before I believe...
  • (unregistered) in reply to

    Can we move on to Context.Response.Redirect then? [8-|]

    Cheers

  • (cs)

    Apart from the general WTFness of it, the worst thing is that if an Exception occurs, he throws it away with any useful info that it might provide, replacing it with a generic "An Error has Occurred" error which tells nobody anything about what happened.

  • (unregistered)

    His coworker must be an old VB 4/5/6 developer... what's they've done is create the Java equivalent of "On Error Goto" the end of the try catch block

    If the ExceptionFlag is set the false, then no stacktrace will ever be printed, and no "An Error has occured" exception will ever be thrown. it will simply "resume next" at the end of the try catch block. [;)]

  • (unregistered)

    WTF.  Doesn't this guy know exceptions are bad for performance?

    <FONT size=2><FONT color=#000099>public string foo()
    {
    boolean</FONT> <FONT color=#000099>exception</FONT>Flag = <FONT color=#000099>true</FONT>;
<FONT color=#000099>try</FONT> {
 initializeResources();
 compareAggregates();
 exceptionFlag = <FONT color=#000099>false</FONT>;
} <FONT color=#000099>catch</FONT>(<FONT color=#000099>Exception</FONT> e) {
 <FONT color=#000099>if</FONT>(exceptionFlag) e.printStackTrace();
}
    return <FONT color=#990000>"An Error has occured";</FONT>
}</FONT>
    <FONT size=2>... and then in the calling code, something like this should be done ...</FONT>
    <FONT size=2>string result = foo();
    if (result.Contains("Error"))
    {
         Response.Write("An Error has occured");
         Response.Redirect("Error.aspx?msg=An+Error+has+occured");
    }


    </FONT>
    <FONT size=2> </FONT>
  • (cs) in reply to

    <FONT style="BACKGROUND-COLOR: #efefef">I have to assume the preceding post is a joke.</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">Please, tell me it is!</FONT>

  • (cs) in reply to
    :

    WTF.  Doesn't this guy know exceptions are bad for performance?

    <FONT size=2><FONT color=#000099>public string foo()
    {
    boolean</FONT> <FONT color=#000099>exception</FONT>Flag = <FONT color=#000099>true</FONT>;
<FONT color=#000099>try</FONT> {
 initializeResources();
 compareAggregates();
 exceptionFlag = <FONT color=#000099>false</FONT>;
} <FONT color=#000099>catch</FONT>(<FONT color=#000099>Exception</FONT> e) {
 <FONT color=#000099>if</FONT>(exceptionFlag) e.printStackTrace();
}
    return <FONT color=#990000>"An Error has occured";</FONT>
}</FONT>
    <FONT size=2>... and then in the calling code, something like this should be done ...</FONT>
    <FONT size=2>string result = foo();
    if (result.Contains("Error"))
    {
         Response.Write("An Error has occured");
         Response.Redirect("Error.aspx?msg=An+Error+has+occured");
    }


    </FONT>
    <FONT size=2> </FONT>

    Trapping errors by parsing the return string just rubs me the wrong way...[*-)]

    Plus this will only work if the method a string type....we can't tell from this code if it is or not.

  • (cs) in reply to
    :

    His coworker must be an old VB 4/5/6 developer... what's they've done is create the Java equivalent of "On Error Goto" the end of the try catch block

    If the ExceptionFlag is set the false, then no stacktrace will ever be printed, and no "An Error has occured" exception will ever be thrown. it will simply "resume next" at the end of the try catch block. Wink

    Wow.  I didn't think you could actually get On Error Resume Next behavior in C#.  That's amazing...  amazingly WTF-ish.

  • (unregistered)

    Actually, this is pretty solid code.

    I tried it using basic HTML and a tin can and it worked wonders.

    It's amazing what you can do with magic.

  • (unregistered)

    this was java, not C#

    (C# uses <FONT color=#0000ff>bool </FONT><FONT color=#000000>not </FONT><FONT color=#0000ff>boolean</FONT><FONT color=#000000>)</FONT>

     

    us C# programmers know better! :P

  • (cs)

    Scott,

    That example was pretty obvious. I was referring more to what Anonymous said, in that not everything that is throwed will be catched.

    So it seems Java and C# differ from this. In Java you can throw every object that is a subclass of Throwable. In C#, everything that can be throwed is a subclass of Exception or the Exception object itself, thus in C#, that code would catch everything. I didn't know this about Java before.

  • (cs) in reply to Razzie

    In Delphi there's something similar. Basically, in Delphi you can raise (throw) any kind of object as if it's an exception. Thus something like:

      raise TComponent.Create(nil);

    will also raise an exception, but one that isn't a standard exception type. You can have quite a lot of confusing fun with that... [;)]

  • (unregistered)

    Katja...you are too young to know about the wonders of Delphi!

  • (cs) in reply to

    Well I for one didn't know they teach Delphi in Holland... at least I haven't seen it yet ;) Apparently, I was wrong!

    But anyway, do you really have to be old and wrinkled to really really know the secrets and fun of Delphi? Poor Katja ;)

  • (cs) in reply to Razzie
    Razzie:

    Well I for one didn't know they teach Delphi in Holland... at least I haven't seen it yet ;) Apparently, I was wrong!

    But anyway, do you really have to be old and wrinkled to really really know the secrets and fun of Delphi? Poor Katja ;)

    Actually, my dad works as a Delphi developer for some software company and he has quite a collection of books too. When I started to get interested in programming about 7 years ago, he decided to teach me some things himself. But you're right. During my studies they're teaching me a bit of all kinds of languages. A bit of C++, a bit of Java, a bit of .NET but no Delphi. No problem for me, though... I know enough about Delphi already. [H]

    And believe me, young people pick up computer skills a lot faster than you old guys... [:P]

  • (cs) in reply to Katja 
    <font size="3">Bad: Response.Redirect("Error.aspx?msg=An+Error+has+occured");

    Why? Opens Error.aspx to an HTML injection attack.
    Consider someone linking to

    Error.aspx?msg=Hi+we+suck+you+should+go+to+competitor.example.com
    </font>
  • (cs) in reply to
    :
    Katja...you are too young to know about the wonders of Delphi!

    Hey, Delphi is still going - the current version of the IDE includes C# as well.

  • (unregistered)

    It looks to me as if the guy is confused by the try/catch structure... he's put the exceptionFlag in there so he doesn't get caught like forgetting the 'break' in a C switch statement.

  • (cs) in reply to
    :

    WTF.  Doesn't this guy know exceptions are bad for performance?

    <FONT size=2><FONT color=#000099>public string foo()
    {
    boolean</FONT> <FONT color=#000099>exception</FONT>Flag = <FONT color=#000099>true</FONT>;
<FONT color=#000099>try</FONT> {
 initializeResources();
 compareAggregates();
 exceptionFlag = <FONT color=#000099>false</FONT>;
} <FONT color=#000099>catch</FONT>(<FONT color=#000099>Exception</FONT> e) {
 <FONT color=#000099>if</FONT>(exceptionFlag) e.printStackTrace();
}
    return <FONT color=#990000>"An Error has occured";</FONT>
}</FONT>
    <FONT size=2>... and then in the calling code, something like this should be done ...</FONT>
    <FONT size=2>string result = foo();
    if (result.Contains("Error"))
    {
         Response.Write("An Error has occured");
         Response.Redirect("Error.aspx?msg=An+Error+has+occured");
    }


    </FONT>
    <FONT size=2> </FONT>

    Must be a Joke, because the cost is from throwing up an exception, not from swallowing it.

    I had to implement an webservice from a spec. They threw away my Data Transfer Object prototype because they could use DataSets. All I wanted was a list of properties so they sent it out to a consultant. If there is an exception, it is caught, a dummy row with an "error" column containing the Exception message is returned.

    Rather than just parsing the return value for "Error", you must check that datatable for the presence of a column called "error".

     

     

  • (unregistered) in reply to
    :
    Actually, catch(Exception e) does not catch everything that can be thrown...


    Actually, yes it will... to be more precise, it will catch any exception that should be caught and the only thing it won't catch is an Error which is the only other class that extends Throwable.

    To quote the JDK javadocs:
    " An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."

    In other words an Error is something much more serious than an exception and usually indicates a problem with the VM itself (RTFM).

    So, if the code your writing throws Errors (particularly if they are then caught) I think we can safely say we've got another WTF on our hands.

    BTW - My favourite is the CoderMalfunctionError (Yes I know its out of context, but it just seems to fit here).


  • (cs) in reply to Katja

    I remember some C++ (which is not my forte) code I worked on last year.  They even threw an integer: the COM error code.  That had me going for a while.

  • (unregistered) in reply to
    :

    WTF.  Doesn't this guy know exceptions are bad for performance?

    <font size="2"><font color="#000099">public string foo()
    [...]</font></font>
    <font size="2">... and then in the calling code, something like this should be done ...</font>
    <font size="2">string result = foo();
    if (result.Contains("Error"))
    {
         Response.Write("An Error has occured");
         Response.Redirect("Error.aspx?msg=An+Error+has+occured");
    }

    </font>


    Your joking right? I think?
  • (unregistered) in reply to
    :

    this was java, not C#

    (C# uses <font color="#0000ff">bool </font><font color="#000000">not </font><font color="#0000ff">boolean</font><font color="#000000">)</font>

    us C# programmers know better! :P



    Oh, so thats what that IO operation "Response.Redirect("YourMomIsHot.html");" that doesn't throw a useful IOException is all about... good thing you C# folks know better!

    Us Java guys are just going to have to deal with the exception if the application can't write to the stream... poor us...

  • (unregistered)

    Do they have a Delphi.net implementation? I can't wait.

  • (cs) in reply to Katja

    Katja:

    And believe me, young people pick up computer skills a lot faster than you old guys... Stick out tongue 

    Hey... leave me out of that ok? Just about to graduate this year myself ;)

  • (unregistered) in reply to
    :
    [image]  wrote:
    Actually, catch(Exception e) does not catch everything that can be thrown...


    Actually, yes it will... to be more precise, it will catch any exception that should be caught and the only thing it won't catch is an Error which is the only other class that extends Throwable.

    Is there something that prevents writing own Throwables that are neither Errors nor Exceptions?

    About the code... I think the biggest wtf there is catching an exception and then instantly throwing a generic "an error occurred"-exception which effectively hides all valuable information about the original exception. The next catch-block will get only the generic exception.

  • (cs) in reply to Razzie

    Leave me out as well, I'm 35 but I pick up damn quickly. 

  • (unregistered) in reply to skicow

    Wouldnt you just edit web.config to turn custom errror page on instead

  • (cs) in reply to
    :
    Do they have a Delphi.net implementation? I can't wait.

    I think Delphi.net came out a few years ago. And that C# Builder came out two or three years ago - Borland now seem to have merged them.

    (Well, once you start targetting CLR underneath, much of the code generation becomes common to both. And C# and Delphi are pretty similar languages in a lot of ways, both being Anders Hejlsberg's babies.)

  • (cs)

    me thinks that this may also be attributed to lazy/sloppy programming, and not necessarily a WTF scenario.

    perhaps   initializeResources();    or   compareAggregates(); used to return a bollean value, based on whether they ''performed'' or not... and the ''if(exception)'  stuff used to just come afterwards... then the programmer discovered try {} catch {} statements and quickly cut & pasted the code around...?

    hm, probably not. occam's razor would argue the wtf scenario far more likely.

    yeah, delphi is still alive and well ( http://dotnet.borland.com/ ). tis a shame no one uses it really nowadays (or am i wrong?), except for shareware-typish software...? katja, i envy you. :) i always wanted my dad to be a soft developer/geek[8-|] who wanted to teach me such stuff as a kid. you have no idea how much faster and easier it is to learn everything that way. nah, instead my father was into business management type stuff... the kind of things I am least interested and worst at...[8-)]

  • (unregistered) in reply to brandonh6k

    so yet again the real problem is VB [:D]

  • (cs) in reply to
    :
    [image]  wrote:
    Actually, catch(Exception e) does not catch everything that can be thrown...


    Actually, yes it will... to be more precise, it will catch any exception that should be caught and the only thing it won't catch is an Error which is the only other class that extends Throwable.

    To quote the JDK javadocs:
    " An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."

    In other words an Error is something much more serious than an exception and usually indicates a problem with the VM itself (RTFM).

    So, if the code your writing throws Errors (particularly if they are then caught) I think we can safely say we've got another WTF on our hands.

    BTW - My favourite is the CoderMalfunctionError (Yes I know its out of context, but it just seems to fit here).


  • (cs) in reply to znaps

    Oops, my text didn't get included there.

    I was saying the quoted text was wrong, because I can create my own subclasses of Throwable, which are not Errors.

    It may not be an everyday thing to do, but it has its uses.

  • (cs) in reply to znaps

    znaps, when would it have it's uses then? I know that in Delphi it could be very funny to raise just a component instead of an exception because most exception handling clauses would not expect to receive a non-exception object and thus they will puke out another exception. Great if you want to bring the application down from your simple piece of code, but what other uses would it have?

  • (unregistered) in reply to Bellinghman

    Bellinghman:
    I think Delphi.net came out a few years ago.

    Are you serious? What's next, PASCAL.NET?

    Eww.

  • (cs) in reply to

    Ehm, Delphi is Pascal, thus Delphi.NET IS Pascal.net...

    And there are several other languages converted to .NET too. I even heard of an ASM.NET which you can use to write .NET applications in, that's right, Assembler code...[:$]

  • (cs) in reply to
    :
    What's next, PASCAL.NET

    Hey, don't knock it. After all, there's VB.NET, and the original VB was even less appropriate as a modern OO language.

    The great attraction of Delphi out there, so far as I could see, was that it was almost as easy to get into as VB, but much better for medium to large projects.

    Not that a poor Delphi programmer couldn't screw up.

    Not that there aren't good VB programmers who could build decent large projects using that language.

    Oh, and Delphi 5 came with a much better set of controls out of the box.

    Delphi was, effectively, a better VB, just using Pascal syntax rather than BASIC.

    (Disclaimer - I am not, nor have I ever been, a Delphi programmer.)

  • (cs) in reply to Katja
    Katja:
    znaps, when would it have it's uses then? I know that in Delphi it could be very funny to raise just a component instead of an exception because most exception handling clauses would not expect to receive a non-exception object and thus they will puke out another exception. Great if you want to bring the application down from your simple piece of code, but what other uses would it have?


    Say I wrote my own VM and wanted to define some new types of "exceptional" happenings. Then I might subclass Throwable (or error). Obviously since I created these new objects, I'll be catching them somewhere or requiring client code to catch them.
  • (cs) in reply to Katja

    Katja:
    Ehm, Delphi is Pascal, thus Delphi.NET IS Pascal.net...

    And there are several other languages converted to .NET too. I even heard of an ASM.NET which you can use to write .NET applications in, that's right, Assembler code...Embarrassed

    You're thinking of this "ASP.NET: ASM to IL compiler"? Read about it some months ago, but haven't used it yet. Maybe I will use it for the next ASP.NET project :)

    List of (most?) .NET languages. Note that there are four Pascal variants listed.

  • (unregistered) in reply to Razzie

    Exception extends Throwable in Java (is this Java?)... so to truly catch every problem, you'd

    try {
    } catch (Throwable e) {
    }

    I had the joy of working with a student who threw that beautiful block around every Exception-throwing method in the project [8-)]

Leave a comment on “You Can Never Be Too Cautious”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article