- 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
People are too quick to just catch a generic Exception. Derp.
Admin
I like the way the code formatter carefully highlights the identifier "function" as if it is a keyword...
Admin
I dont understand where the recursion is and what the problem is: getPersonsInformation and lookup.getPersonsInformation can surely be different methods.
Admin
public static bool Comment(){ try { return PostCommentFrist(); } catch (Exeption e) { return Comment(); } }
Admin
The recursion is in the catch-block where the method calls itself with the original parameters.
Admin
The recursion is in the catch part of the exception handler. It calls itself with the attributes it was passed.
Admin
Do or do not. There is no try.
(I guess Yoda wasn't a programmer)
Admin
Thanks. Looked in the wrong spot. So there will only be a recursion if the desired Service was not available. Adding a sleep() at the beginning of the catch-clause and this code is a little less wtf.
Admin
If the compiler is smart enough, it can see that this is a case of tail recursion and avoid stack overflow. That still doesn't mean that this code isn't retarded as fuck.
Admin
We are talking about Java compiler here. It won't even filter out needless assignments, and you expect it to notice tail recursion?
Admin
But suppose you add a 1 second sleep. While the default stack may not be very deep, it certainly allows hundreds to thousands of simple calls. Then it could take an hour to exhaust the stack. And still end in a rather uninformative "stack overflow" exception.
No, this method is quite exceptional. I hope.
Admin
Admin
"There will one day be lemon-soaked paper napkins. Till then there will be a short delay. Please return to your seat."
Admin
Would be more amusing if lookup.getPersonsInformation() did a lookup on an external paid-for data service, in which case a stack overflow is the least of their worries. BailiffsComingToCollectOnLargeDebtException perhaps?
Admin
lookup.getPersonsInformation(loginInfo, department, function) might throw an exception on its own right if:
And then you have to accomodate all the exceptions that might be thrown by code that lookup.getPersonsInformation() uses and does not deal with itself.
Admin
+1 HHG
Admin
Looks like the kind of stuff I see around here. Of course we have more than enough of the empty catch (swallowing any exception and continuing as if nothing happened).
It's amazingly hard to convince people that "they're doing it wrong..."
Admin
And about half a year ago you laughed at me, when I said that an empty catch block is not the worst. Now you have it.
Admin
Work harder, meatbots! Stack deeper!
Admin
I'm higher than high Lower than deep I'm doing it wrong Singing along
Admin
Code formatter just think it's a C-Pascal. It is rare dialect of Pascal that has c-style declaration (type first, identifier last) and ability to define identifiers anywhere in code (no var or const block, though type block is still there), but otherwise it has still Pascal syntax where function is still a keyword (functions and procedures are declared same way as in pascal). Though frankly it seems more like C-Pascal++ as it has classes.
Admin
Public Function DoIt As Boolean On Error Goto Exit_Function ... DoIt = True Exit FunctionExit_Function: DoIt = False Exit Function
This way, it works, or it does not, and you can find out which.
Admin
Sometimes it is really reasonable to just ignore the exception, I did write code that have empty catch block...
To put simply, I need to loop URL that formatted something like http://www.example.com/XXX (XXX=000-999), but some URL simply didn't exist and I don't care. However the library would throw HTTP exception on 404 not found error. Of course I would write an empty catch block...
Admin
The sleep() might allow you to avoid some causes of the exception (e.g. throw new TemporaryFailureException("Please try again in 500ms") (*)), but others (especially things like NotAuthorisedException("I HATE YOU")) will be permanent, so as mentioned above you will merely overflow the stack more slowly.
(*) Yes, a "try again in 500ms" error should just wait 500ms and try again itself. It's just a stupid example, so sue me, OK.
Admin
Now I got a song going through my head, based on the chorus of Kenny Roger's "The Gambler":
Hmm, makes me think of how to represent the next line. Maybe as a SQL error: COUNT() is not valid on field type Currency during Table.sitting operation.Admin
The throws declaration in the method signature for an exception that can't be thrown due to the catch is a nice touch.
Admin
So you're advising him to:
(a) reduce the wait time by half. (b) move the recursion up a level so that you are adding an additional call to the stack with each retry.
... meaning, you will fill out the call stack twice as fast!
Nice going genius.
Admin
If at first you don't succeed, try try again?
Admin
Ignoring One exception might be OK. But need to ensure that you don't catch exceptions of other problems
As you can see, the culprit today will catch any exception and try again (even if it's "Out Of Memory").
Admin
Admin
I know he needed a global to store a number of tries. That way he only recurses a limited number of times.
If(_numberOfTries < MAX_NUMBER_OF_TRIES) then sleep(_numberOfTries * 1000) getPersonsInformation(person, department) Else throw New Exception("Something doesn't work") 'Must hide original exception/sarcasm
Admin
But Java programmers tend to not write deeply recursive code anyway. They're like C and C++ in that. If they wanted to write recursive stuff all over the place, they'd use Scala or Clojure (where the initial compiler is allowed and expected to do much more extensive optimisations)…
Admin
Admin
Admin
Could
getPersonsInformation(loginInfo, department, function)
be more specific and more likely to fail than
getPersonsInformation(department,function)
maybe the second causes some default values to be used and so is safe to run?
Admin
Putting on my asbestos suit... Okay.
TRWTF is exceptions, period. I have yet to encounter a situation where exception processing delivers the same level of quality, for the work involved, as a regimen of simply returning an error and then checking the return for errors.
It's true that exceptions provide the flexibility of dealing with errors somewhere other than at the point of the function call, but I have not yet seen a situation where the error was better handled elsewhere. Maybe there is, but in my experience there isn't.
Admin
Admin
Actually, we do not even know if ServiceLocator is a class provided by a third party or if its code is under the auspices of the coder who wrote the getPersonsInformation(department,function) wrapper around it.
Admin
You do realize that ben said it would make it "a little less wtf", yes? Are you disagreeing with this? Are you saying that code that recursively cycles constantly based on a catch-all exception is BETTER than code that cycles with a delay based on a catch-all exception? If so, please turn in your programming license at the door.
Obviously the implementation is poor, but the comments saying that infinite recursion is an absolute ("the only reason this won’t run forever...", "...when there is any error") are premature. Without knowing what lookup.getPersonsInformation does (or getLookupLocal, for that matter), we can't say that. In some (most?) cases, the problem may not be permanent. Adding a sleep would:
It doesn't fix the code, but it certainly does make it slightly more sane.
Admin
I wonder if there was originally a re-throw in the catch block.
Admin
With exceptions you can far more easily deal with "families" of errors. With error codes you have to evaluate every single error code and determine what to do with it. With exceptions, this is far easier because you can group them by Interfaces, e.g. ICredentialException, INetworkException etc.
If future versions of your code introduce new error conditions, with error codes you will most likely have to update your error handling (unless you just have generic error handling, "if res < 0..."). With exceptions things are a lot easier - as long as you catch by interface, it doesn't matter if the a new version introduces a new exception.
Of course, you could emulate that with returning error objects instead of error codes, but I haven't seen that anywhere yet.
Admin
Okay, let's count other WTFs:
Admin
Yep, I didn't read the name of the collection
Admin
Admin
Well that's as maybe. but what you do not do here is:
} catch (Exception e) { }What you're supposed to do is:
} catch (UnknownURLException uue) { } catch (OtherSortsOfException e) { ... do something appropriate }Just catching and swallowing every exception when you're only interested in the one is abysmal practice.
Admin
If the lookup.getPersonsInformation function randomly throws an error instead of returning the correct (existing) result, then it is TRWTF. Still, the "better" way to do this would be to iterate a finite number of times and silently log the exceptions, then stick in a last-ditch attempt without any catch so that instead of throwing a nondescript stack overflow error you'll get the error that the function actually threw.
Admin
In most of our applications, the type of error is only of interest to the developer, so any error return is as bad as any other, and so checking for the non-error return is good enough in most applications.
As for future versions returning new error codes, if we already check for the non-error return, the new error codes are still only interesting to the developer.
The only time the specific error is important to the user is if there is something the user can do to make another attempt successful.
Admin
I wonder whether this is just a pre-coffee blunder that didn't get noticed on code delivery.
I have on a plurality of occasions written code with the following execrable pattern:
private String attr; : : public String getAttr () { return this.getAttr(); }when I really meant to type:
private String attr; : : public String getAttr () { return this.attr; }The difference between the blooper above and the OP is the fact that the above is instantly obvious the first time it is run. The OP may never get tested if the method serving it is sufficiently reliable and has never thrown an exception during its lifecycle.
The real WTF of course is that unit testing didn't catch it.
Admin
Well of course it's a WTF. He should have written it with a loop:
Collection persons = null; while (true) { try { persons = lookup.getPersonsInformation(loginInfo, department, function); break; } catch(Exception e) { //try, try again } } return persons;Recursion isn't the solution for everything!
Admin
If at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, try if at first you don't succeed, BRAIN SEIZURE no more memory left to remember what I was doing!!!