- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
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.
Admin
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:
number 4 is the real killer, of course... ;o)
Admin
I hope that's not created by someone you work with. If it is, I weep for you.
Admin
he probably did this because .Net throws an exception if you do a redirect inside a try block. You have to either redirect with the 'endResponse' flag set to false, or catch a ThreadAbort exception and ignore it.
Admin
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 :)
Admin
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.
Admin
Seriously. You're not fit to be a programmer.
Admin
Well, goto got stigmatized and now many are using Exceptions for flow control (and sometimes write better readable code).
Goto wasn't that bad.
Admin
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.
Admin
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???)
Admin
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
Admin
GOTOs don't kill applications- Programmers kill applications.
Admin
Admin
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.
Admin
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.
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
If you're interested, I heard of a recent vacancy for that very profile.
Admin
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?
Admin
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.
Admin
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.
Admin
They have a vacancy for one.
SCNR.
Admin
goto shouldn't have even come up...
Admin
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
Admin
This just made me laugh! I never would have thought of this one.
Admin
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.
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.
Admin
Well, there was also "On Error Resume Next". I have seen code that actually used it. It was awful.
Admin
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.
Admin
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
Admin
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...
Admin
[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).
Admin
Chariot-running experience required for that position.
Admin
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".
Admin
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).
Admin
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:
Admin
so.. basically the whole app wa one big exception handler, maybe the most complex one ever.-
Admin
Admin
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.
Admin
Guns don't kill people- People kill peoble --> guns just help
Admin
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.
Admin
Admin
Sounds like a case of the Mondays.
Admin
"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.
Admin
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.
Admin
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.
Admin
Admin