Comment On The RedirectException

Impressive - but not all that uncommon to use exceptions for logical rerouting since GOTO is outlawed.

At least it was properly named for what it did.

It's at the end of each code block in an if/elseif/else statement. Removing the try/catch block and exception throwing would produce the exact same results.

ouch...

you see the same form of abuse in Java a lot: using exceptions for flow control...

*absolutely* worst thing I ever saw was this:

void someMethod()

{

   try

   {

      ... // ~300 LOC

      if (someExitCondition)

      {

         String s = null;

         s.length();

      }

      ... // ~300 LOC

   }

   catch(Exception ex)

   {}

}

The developer's worst sins in ascending cruelty:

1) creating a much too long method body (the whole system was certainly not OO)
2) not knowing about the "throw" statement and using a dumb deliberate error condition to force an exception
3) using an empty "catch" block with a generic exception type, thus rendering all real exception handling completely moot in this method
4) not knowing about the "return" statement (!!!)

number 4 is the real killer, of course... ;o)

Woohoo:

ouch...

you see the same form of abuse in Java a lot: using exceptions for flow control...

*absolutely* worst thing I ever saw was this:

/** SNIP **/

I hope that's not created by someone you work with. If it is, I weep for you.

I hate to say it but I have been tempted by this before. Its not so much just a substitute for GOTO because of the stack unwinding and deallocation happening just the way you'd want it.

I did decide against it :)

I've seen worse stuff. I've been working methods with code wrapped around a try...except block, and the except block stored the exception message in a string! Sometimes it's really, really, REALLY difficult to debug the code, specially when we're dealing with lots of methods calling each other and a single exception is ignored.
Oh, and the last guy didn't know about static variables. There is a "ClassFunctions" class with lots of utility vars and functions. No idea why.
BTW: the Class prefix is required. Yes, it is very, very stupid, but it's required, documented and I can be punished for not following such ridiculous standard. We don't even have source control, we don't have a decent bug tracking system, but we have a document telling us to prefix classes with "Class". Go figure.

I hate to say it but I have been tempted by this before.

Go. Find. Another. Job.

Seriously. You're not fit to be a programmer.

Well, goto got stigmatized and now many are using Exceptions for flow control (and sometimes write better readable code).

Goto wasn't that bad.

Why? My Eyes!!! But... why? Please, go find the person who did this and ask him/her in wtf he was thinking of. Now my mind hurts. There goes my Monday productivity.

hmmmm... Firefox spell checker thinks that monday should be Monday only.

Joe Scylla:

Well, goto got stigmatized and now many are using Exceptions for flow control (and sometimes write better readable code).

Goto wasn't that bad.

What I find ironic is the the aboslute belief that Goto's are bad, yet when you get down to the bare metal thats fundementally what a CPU runs on.

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself (damn am I starting to sound like an NRA spokesperson???)

Wow!

Exceptions are not only meant for error handling, it's a useful mechanism built into the language.

Saying that this is like GOTOs because you could do it with ifs/etc applies to error handling also. Take a minute to think before posting template answers.

In certain situations throwing something is somewhat more elegant, and while it is not recommended, it is certainly not frowned upon.

FYI TurboGears uses the same redirect method:
raise redirect("url")

http://www.lucasmanual.com/mywiki/TurboGears#head-b10112a311bd01497b2e06f32a9b3f0cb9d52561

OzPeter:

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself (damn am I starting to sound like an NRA spokesperson???)

Welcome to the NGA - the National Goto Association. Tonight we're having pasta for our association dinner; spaghetti, to be exact.

T:

Wow!

Exceptions are not only meant for error handling, it's a useful mechanism built into the language.

But you have to agree that they are intended to be used for exceptional circumstances. This just looks like it runs them as a matter of course for every option the user has.

OzPeter:

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself (damn am I starting to sound like an NRA spokesperson???)

As long as you don't go riding in chariots with stone tablets, shouting profanities at statues while eating green cookies, you'll be just fine.

Captcha: amet
And last time it was dolor.
I think it's feasable for a dedicated spammer to write an algoritm that would also try lorem, ipsum, and friends.

Woohoo:

4) not knowing about the "return" statement (!!!)

number 4 is the real killer, of course... ;o)

Our coding standards prohibit the use of "return" anywhere but the end of a method, the theory being that it's harder to read the method as a whole if you can jump out from anywhere. (We do allow "break" though, and in C you can use "goto EXIT_LABEL" - go figure.)

I hate to say it but I have been tempted by this before.

Go. Find. Another. Job.

Seriously. You're not fit to be a programmer.

That is a stupid thing to say. Making errors is the mark of good programmers, if you are willing to learn from them.

I am probably a better programmer than you are, but I have been tempted by this, and actually used it once in some form of it in a project. It did seem the easiest solution (it was for reading a file, and I generated an EndOfFile exception at the end). It was a stupid idea, but it did work and was easy to implement. Of course, the drawback is in maintenance/evolution, and I ended up rewriting it sanely a few years later (a 15 minutes job).

So, I think it is natural to be tempted by it, and programmers are quite good at persuading themselves that the first idea that crosses their mind is the correct one ("well, that situation [end-of-file, or redirection] is exceptional, so it make sense to use an exception for it, so I don't clutter the normal code path with code that handles that specific case"). It takes experience to understand why it is such a bad idea, and experience only comes with errors.

Btw, I think the CS courses should teach maintenance, as that is 80% of the work of a programmer (and in the other 20%, when you write new code, you actually have to think about maintenance, by you or others). Something like asking students to make modifications to code with design flaws, so they could learn the hard way why some ideas are bad.

What I find ironic is the the aboslute belief that Goto's are bad, yet when you get down to the bare metal thats fundementally what a CPU runs on.

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself (damn am I starting to sound like an NRA spokesperson???)

I direct you to Dijkstra:
http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

He had very specific reasons why he considered goto to be a bad idea.

T:

Exceptions are not only meant for error handling, it's a useful mechanism built into the language.

They're not meant for normal things, either. They're called "exceptions" for a reason. They're to handle exceptional things - things that you don't expect to happen during normal execution. Things like hard-coded redirects because conditions aren't met isn't unexpected; obviously you DID expect them, because you wrote the code to handle them with the exception. Handle them the correct way instead.

Using exceptions to do things you expect is stupid. There's overhead involved in setting up things to raise an exception. Wasting that overhead for something you know will probably happens is idiotic. If you write code that way, stay away from my shop.

OzPeter:

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself (damn am I starting to sound like an NRA spokesperson???)

If you're interested, I heard of a recent vacancy for that very profile.

I know someone said that ASP.NET throws an exception if you try to redirect inside of a try block, however I'm willing to be the try block is there because there is some logic right there on that ASPX page that should be in the DAL or BLL...

If the code was in the right place in the first place he probably wouldn't have had to use a try/catch in the page itself, thereby freeing him up to do something more sensible in the ASPX page.

Oh, and GOTO's r teh suck. Not because they cause a performance problem - because they are hard to friggin read. They cause a linear line of thought in your brain to have to branch off to some other part of the code. It's ugly too. If you need to break that code out why not just write a private method to handle it?

I'm working on a derivative of xchat 1.0 (with some features backported from xchat 2.x) which we're cleaning up for efficiency and sanity - it's a goto nightmare. I was working on removing all gotos from the code, and had a hell of a time figuring out what the author wanted to do. Most of the time though, I could rewrite the functions to not use goto without even introducing any new variables, and the legibility has improved greatly.

Captcha: plaga. Indeed.

BadReferenceGuy:

I direct you to Dijkstra:
http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

He had very specific reasons why he considered goto to be a bad idea.

Oh I totally agree with Dijkstra and I have been using object orientated methods in my own programming since the 80's.

My point was that people blindly demonise Gotos without realising the systems they use are actually built on them at a fundemental level. In fact "continue" and "break" statements are only thinly disguised Gotos as well.

OzPeter:

[...](damn am I starting to sound like an NRA spokesperson???)

They have a vacancy for one.

SCNR.

Joe Scylla:

Well, goto got stigmatized and now many are using Exceptions for flow control (and sometimes write better readable code).

Goto wasn't that bad.

goto is just as unnecessary in this particular case! Sadly, I've been developing with ASP/VBScript for the past year so .NET is more of a dream to me at this point, but you should achieve the exact same behavior more efficiently and with less code with something like...

if(!isCustomer) 

{

    -- snip lots of code to process a new order --

   Response.Redirect("/Orders/NewOrderShipping.aspx")

}

else if(isQuickOrder)

{

    -- snip more order processing code --

    Response.Redirect("/Orders/Confirm.aspx")

}

else

{

    -- snip even more order processing code --

    Response.Redirect("/Orders/SelectShipping.aspx")

}

goto shouldn't have even come up...

Back in the pre-dotnet days I worked at a company which used VB as our development language. Its only built-in error trapping was by means of "On Error Goto [label]". The most common label chosen for the error handling routine was "Hell":

On Error Goto Hell

This just made me laugh! I never would have thought of this one.

OzPeter:

What I find ironic is the the aboslute belief that Goto's are bad, yet when you get down to the bare metal thats fundementally what a CPU runs on.

Yes, this must be why we all write machine code manually - after all that is fundamentally what a CPU runs on.

Or perhaps programming languages and compilers where invented for a reason, such as abstracting away from low-level machine implementations.

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself

As an implementation mechanism (where programmers don't have to look at them), goto's are fine. As a high-level control mechanism, they are harmful, because they make it much harder for programmers to form a mental model of the running process (keeping track, in your mind, what happens when you run the program).

That is at least my understanding of the main point in the famous goto considered harmful paper.

FredSaw:

Back in the pre-dotnet days I worked at a company which used VB as our development language. Its only built-in error trapping was by means of "On Error Goto [label]".

Well, there was also "On Error Resume Next". I have seen code that actually used it. It was awful.

Woohoo:

ouch...

you see the same form of abuse in Java a lot: using exceptions for flow control...
<snip>
The developer's worst sins in ascending cruelty:

1) creating a much too long method body (the whole system was certainly not OO)
2) not knowing about the "throw" statement and using a dumb deliberate error condition to force an exception
3) using an empty "catch" block with a generic exception type, thus rendering all real exception handling completely moot in this method
4) not knowing about the "return" statement (!!!)

number 4 is the real killer, of course... ;o)

I've seen the equivalent of 3) some years ago on a Delphi project I had taken over. In that case, it actually masked a few other errors in the code that SHOULD have thrown exceptions. As a result, the application proceeded with wrong and/or incomplete intermediate results.

I'd like to note, however, that the guy who wrote it was not a programmer by training. He had to help out in software development anyway, with not so bright results.

FredSaw:

Back in the pre-dotnet days I worked at a company which used VB as our development language. Its only built-in error trapping was by means of "On Error Goto [label]".On Error Goto Hell

In the dotnet days now I sometimes work in an environment that uses VBScript, which is not VB. In VBScript your only means of handling errors is "On Error Resume Next", we don't even have the luxury of "On Error Goto".

And yes I also had to invent a time machine in order to get to work 10 hours before I got up in the morning after spending 14 hours walking up hill each way in a snow storm

NiceWTF:

As an implementation mechanism (where programmers don't have to look at them), goto's are fine. As a high-level control mechanism, they are harmful, because they make it much harder for programmers to form a mental model of the running process (keeping track, in your mind, what happens when you run the program).

That is at least my understanding of the main point in the famous goto considered harmful paper.

There are times where goto is the cleanest, most efficient, and best solution to a coding structure. They are relatively rare though. Saying that goto is only useful under the surface is just as bad as using goto when other control mechanisms should be used.

OJ:

Well, there was also "On Error Resume Next". I have seen code that actually used it. It was awful.

I think he's referring to actual VB (VB6, perhaps) wheras (AFAIK) On Error GoTo Next is a VBScript hack to ignore errors and allow the programmer to decide what to do by checking for errors manually (i.e. If Err.Number <> 0 Then). Or, if he so choses, let the script run ignoring the error and hope nothing bad happens. ::)

Addendum (2008-04-07 11:20):
Ahh, I meant On Error Resume Next. :-X To indicate that you want VBScript to again halt execution on an error you would then use On Error Goto 0. I clearly mixed them up...

I've found a few instances where it is necessary to use this construct in VBScript, but I generally wrap it in a function and signal errors with return values so they can be handled gracefully. I also make sure to re-enable script halting at the end of the function...

[quote user="xtremezone"][quote user="NiceWTF"]
[quote user="OJ"]Well, there was also "On Error Resume Next". I have seen code that actually used it. It was awful.[/quote]I think he's referring to actual VB (VB6, perhaps) wheras (AFAIK) On Error GoTo Next is a VBScript hack to ignore errors and allow the programmer to decide what to do by checking for errors manually (i.e. If Err.Number <> 0 Then). Or, if he so choses, let the script run ignoring the error and hope nothing bad happens. ::)[/quote]

If I am not entirely mistaken, QBasic and VBs at least up to 4 had both On Error Goto and On Error Resume Next. There were people who actually chose Resume Next (well, I did too when I dabbled in QBasic but I was maybe 14 at the time).

Waffle:

OzPeter:

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself (damn am I starting to sound like an NRA spokesperson???)

If you're interested, I heard of a recent vacancy for that very profile.

Chariot-running experience required for that position.

OzPeter:

And yes I also had to invent a time machine in order to get to work 10 hours before I got up in the morning after spending 14 hours walking up hill each way in a snow storm

Lol--yeah, I walked that hill, too. :)

I didn't always read On Error Goto Hell as the instruction, "go to hell". Sometimes in my mind it read the same way as the famous "dll hell" phrase that was so overused during the fanfare heralding .Net: "Goto hell".

fred:

I hate to say it but I have been tempted by this before.

Go. Find. Another. Job.

Seriously. You're not fit to be a programmer.

That is a stupid thing to say. Making errors is the mark of good programmers, if you are willing to learn from them.

I am probably a better programmer than you are, but I have been tempted by this, and actually used it once in some form of it in a project. It did seem the easiest solution (it was for reading a file, and I generated an EndOfFile exception at the end). It was a stupid idea, but it did work and was easy to implement. Of course, the drawback is in maintenance/evolution, and I ended up rewriting it sanely a few years later (a 15 minutes job).

So, I think it is natural to be tempted by it, and programmers are quite good at persuading themselves that the first idea that crosses their mind is the correct one ("well, that situation [end-of-file, or redirection] is exceptional, so it make sense to use an exception for it, so I don't clutter the normal code path with code that handles that specific case"). It takes experience to understand why it is such a bad idea, and experience only comes with errors.

Btw, I think the CS courses should teach maintenance, as that is 80% of the work of a programmer (and in the other 20%, when you write new code, you actually have to think about maintenance, by you or others). Something like asking students to make modifications to code with design flaws, so they could learn the hard way why some ideas are bad.

That was actually one of the first things we did on my university on our first c++ course. We got a few programs that either didnt work properly, or not at all, with the job of finding the errors in them. It was the hardest part of that whole course, but you learned a fair bit about pointer errors when digging around unknown code for a REALLY weird error (and with c++, weird errors can be really weird errors). Especially if you havent been programming much previously and the teacher is a code structure nazi (and for that I thank him immensely).

NiceWTF:

...snipped...

That is at least my understanding of the main point in the famous goto considered harmful paper.

Some people also raise their voice for goto:
Code Complete 16.1 Using gotos
An Argument for the Use of goto Statements

imho the best summary about the use of goto:

Use of gotos is a matter of religion. My dogma is that in modern languages, you can easily replace nine out of ten gotos with equivalent structured constructs. In these simple cases, you should replace gotos out of habit. In the hard cases, you can still exorcise the goto in nine out of ten cases. In these cases, you can break the code into smaller routines; use nested ifs; test and retest a status variable; or restructure a conditional. Eliminating the goto is harder in these cases, but it's good mental exercise, and the techniques discussed in this section give you the tools to do it.

In the remaining one case out of 100 in which a goto is a legitimate solution to the problem, document it clearly and use it.

so.. basically the whole app wa one big exception handler, maybe the most complex one ever.-

Woohoo:

4) not knowing about the "return" statement (!!!)

number 4 is the real killer, of course... ;o)

There are some schools of thought which abjure the use of

return

statements other than as the last line of a function or method.

I was forced to work with VBA only a few months back. And I did use "On Error GoTo", because there's no other way, and "On Error Resume Next" complete with checking for the value of the "Err" variable.

I did include more comments than code in that segment though, most of it was ranting about how much VBA's error handling sucks.

Matt:

OzPeter:

Joe Scylla:

Well, goto got stigmatized and now many are using Exceptions for flow control (and sometimes write better readable code).

Goto wasn't that bad.

What I find ironic is the the aboslute belief that Goto's are bad, yet when you get down to the bare metal thats fundementally what a CPU runs on.

Like all things Goto's are a tool, and its the misuse of the tool that is bad, not the tool itself (damn am I starting to sound like an NRA spokesperson???)

GOTOs don't kill applications- Programmers kill applications.

Guns don't kill people- People kill peoble --> guns just help

OzPeter:

And yes I also had to invent a time machine in order to get to work 10 hours before I got up in the morning after spending 14 hours walking up hill each way in a snow storm

Invent a time machine? That's nothing. Back in my day we 'ad to invent time itself, which we'd 'ewn from the primordial soup, and come up with a supporting mathmatical model (with equations) to explain it 't pit owner, that's before 47 'our walk home on our bare hand, at which point father'd declare us an imaginary construct and we'd cease to exist; and be bloody glad of it too.

ZippoLag:

so.. basically the whole app wa one big exception handler, maybe the most complex one ever.-

A clbuttic case of the exception becoming the rule.

ubersoldat:

Why? My Eyes!!! But... why? Please, go find the person who did this and ask him/her in wtf he was thinking of. Now my mind hurts. There goes my Monday productivity.

hmmmm... Firefox spell checker thinks that monday should be Monday only.

Sounds like a case of the Mondays.

OJ:

Well, there was also "On Error Resume Next". I have seen code that actually used it. It was awful.

"Awful" is putting it lightly. Try maintaining code that *relies* on it to even work, because the code calls methods on objects prior to creating them, and references nonexistent methods/properties from include files six levels deep.

I had a professor who announced that GOTO statements were okay. The class was aghast! Then he said that labels were evil. He had a point. When you come across a GOTO statement, you know exactly what it's going to do. It's unconditional...no thinking or interpretation required. However, when you see a label in the code, you don't know where it's being called or from how many places or for what reasons. (Well, not without a lot of effort.)

The net effect of his advice matched that of Dijkstra: no labels, so no GOTOs. We breathed sighs of relief.

Joe Scylla:

Some people also raise their voice for goto:
Code Complete 16.1 Using gotos
An Argument for the Use of goto Statements

To summarize:

- Goto code can be hard to translate into Goto-less code. What does that say about the readability of Goto code?
- Goto is good for handling errors. However, neither of those two links show exception handling in any form.
- Goto is good to avoid duplicate code... Except it's trivial to wrap the duplicate code in a new function.

The error handling bit is interesting to me... I suspect that any case for which Goto is still useful is likely a case that would be better turned into a "goto in disguise", like exception handling, continue/break in loops, return, etc. While they may be effectively little more than goto, they're generally much more readable, and they give the compiler more information, which is always a good thing.

For example: Exception handling, in its simplest form, is a goto. But it will also unroll the stack, firing off destructors along the way, and it will only jump farther up the call stack, not to some completely random label somewhere in the code. It is thus more structured than Goto, and designed to replace a specific use of goto.

If we're really down to only one case out of 100 in which goto is a legitimate solution, we can't be very many syntactical hacks away from removing it entirely.

ubersoldat:

Why? My Eyes!!! But... why? Please, go find the person who did this and ask him/her in wtf he was thinking of. Now my mind hurts. There goes my Monday productivity.

hmmmm... Firefox spell checker thinks that monday should be Monday only.

It is capitalized in American English.

Martin Dreier:

OzPeter:

[...](damn am I starting to sound like an NRA spokesperson???)

They have a vacancy for one.

SCNR.

He retired five years ago when he was diagnosed with Alzheimer's.