Comment On You Can Never Be Too Cautious

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

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.

:

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

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.

Razzie:

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

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

}

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?

:

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

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

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

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

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



Cheers

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.

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. [;)]

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

public string foo()
{
boolean exceptionFlag = true;

try {

 initializeResources();

 compareAggregates();

 exceptionFlag = false;

} catch(Exception e) {

 if(exceptionFlag) e.printStackTrace();

}
return "An Error has occured";

}

... and then in the calling code, something like this should be done ...

string result = foo();
if (result.Contains("Error"))
{
     Response.Write("An Error has occured");
     Response.Redirect("Error.aspx?msg=An+Error+has+occured");
}

I have to assume the preceding post is a joke.

Please, tell me it is!

:

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

public string foo()
{
boolean exceptionFlag = true;

try {

 initializeResources();

 compareAggregates();

 exceptionFlag = false;

} catch(Exception e) {

 if(exceptionFlag) e.printStackTrace();

}
return "An Error has occured";

}

... and then in the calling code, something like this should be done ...

string result = foo();
if (result.Contains("Error"))
{
     Response.Write("An Error has occured");
     Response.Redirect("Error.aspx?msg=An+Error+has+occured");
}

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.

:

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.

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

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.

this was java, not C#

(C# uses bool not boolean)

 

us C# programmers know better! :P

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.

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... [;)]

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

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

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]

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

:

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.

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.

:

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

public string foo()
{
boolean exceptionFlag = true;

try {

 initializeResources();

 compareAggregates();

 exceptionFlag = false;

} catch(Exception e) {

 if(exceptionFlag) e.printStackTrace();

}
return "An Error has occured";

}

... and then in the calling code, something like this should be done ...

string result = foo();
if (result.Contains("Error"))
{
     Response.Write("An Error has occured");
     Response.Redirect("Error.aspx?msg=An+Error+has+occured");
}

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

 

 

:

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

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.

:

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

public string foo()
[...]

... and then in the calling code, something like this should be done ...

string result = foo();
if (result.Contains("Error"))
{
     Response.Write("An Error has occured");
     Response.Redirect("Error.aspx?msg=An+Error+has+occured");
}

Your joking right? I think?

:

this was java, not C#

(C# uses bool not boolean)

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

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

Katja:

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

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

:

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.

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

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

:

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

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-)]

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

:

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

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.

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?

Bellinghman:

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

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

Eww.

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...[:$]

:

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

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.

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

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.

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-)]