The Daily WTF: Curious Perversions in Information Technology

2014-03-07 Reply Admin

D B:
Mat:
If at first you don't succeed, try try again?

If at frist you don't succeed, try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try

Wrong, wrong, wrong, all wrong.

"If at first you don't succeed, try and try again. But if you still don't succeed after the third time, give up for the moment, no need to get obsessive about it."

Not sure who said that, some successful entrepreneur of early C20, may have been Ford, may have been Edison. I paraphrased it from memory.

The same can be said for catching errors and exceptions from external resources -- repeat the exercise (after a short delay) in case there's something transient.

2014-03-07 Reply Admin

Mick:
S:
Mick:
I put it to you, Your Honour, that lots of people think thatg functioning error handling is more important than minimising the likelihood of errors in the first place.....

Errors will happen, no matter how much you minimise the likelihood, and when they do, the language needs to make it easy to find them. And while tail-recursion is a useful feature, it's not going to make any great difference in reducing the frequency of errors.
errors will happen, and you need to handle them. Granted. But that doens't make excpetion handling more important than avoiding errors/exception.

Dedicated attention by a developer to the specific exception handling that will be needed on a project is more likely to direct the developer's attention onto the areas which are likely to throw those exceptions. Hence, because of the resulting greater care and attention, mistakes caused by inadequate problem analysis are less likely to happen.

Having said that, the exceptions that you are most interested in capturing and doing something useful with are those which are outside your direct control: availability of external resources are a case in point. At a particularly primitive level (I know this isn't likely in these current days of commons.io) consider attempting to write a file to a directory. If the directory does not exist it will throw an exception -- but if you catch that specific exception you can direct your application to generate that directory.

The exception structure is there, it's a tool to be used, and it can be misused as egregiously as any other. To those who complain about it, I will call to mind the proverb about bad workmen.

2014-03-07 Reply Admin

ben:
I dont understand where the recursion is and what the problem is: getPersonsInformation and lookup.getPersonsInformation can surely be different methods.

You don't even understand the word "recursion" do you?

(Clue: there's only one function on the page and recursion is when...what?

2014-03-07 Reply Admin

Juste replace public Collection getPersonsInformation(String department,String function) throws LookupException { by public Collection getPersonsInformation(String department,String function) throws LoopUpException {

2014-03-07 Reply Admin

S:
Peter Wolff:
Ironically, I don't think the programmer found this gem of code on stackoverflow.com.

Heh... about 6 months ago, I was trying to track down the cause of a StackOverflowError in some third-party code I was using.

Unfortunately, it's now utterly impossible to search for that error... that otherwise useful website just drowns out everything - and you can't easily exclude it from results, because that's where you'd expect to find them...

Well, you must be doing something wrong, because just searching for "stackoverflowerror" gives this...

java - What is a stack overflow error? - Stack Overflow StackOverflowError (Java Platform SE 7 ) - Oracle Documentation How to solve the java.lang.StackOverflowError | WebRatio StackOverflowError - Adobe ActionScript® 3 (AS3 ) API Reference StackOverflowError | Android Developers Diagnosing and Resolving StackOverflowError - Inspired by Actual ... Bug 53871 – java.lang.StackOverflowError on deploying a web ... etc.

chubertdev · 2014-03-07 Reply Admin

QJo:
chubertdev:
asdf:
chubertdev:
asdf:
else {throw;} - not else {throw hex;}

Six of one.

Sure, if you don't care about the whole stack trace and instead want to change where the error came from.

IMHO, I think that developers have become too dependent on the stack trace for exceptions.

That's like what one lungfish says to another lungfish: "IMHO, I think that land-dwellers have become too dependent upon legs for locomotion."

It's already being logged in that catch, anything after that is gravy.

2014-03-07 Reply Admin

If at first you don't succeed, destroy all evidence of the attempt and execute anyone who helped you.

2014-03-07 Reply Admin

ben:
I dont understand where the recursion is and what the problem is: getPersonsInformation and lookup.getPersonsInformation can surely be different methods.

In order to understand recursion you must first understand recursion. I don't have much hope that you will come to this understanding.

2014-03-07 Reply Admin

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

I actually agree with you 100%. I use exception handling very rarely, and usually when I didn't write the class that throws the exception. I have written classes that throw exceptions, but only under the rarest of circumstances. 99% of the time I will do exactly what you suggest, return an error and do something else on that return.

2014-03-07 Reply Admin

Mick:
OO allows all the interface stuff, which does add your 'families of errors' concept, but that can be easily simulated by things like: - Major and Minor error codes (stroed in an error object if you like) - Grouping Errors eg: 0x0000 = no error, 0x0001 to 0x000F are network errors, 0x0010 - 0x001F are someit else errors, etc - etc
I can sort of imagine advantages to an exception based approach, but I can also think of advantages to an error-code based approach (and let's remember not all languages are OO....).

Then again, when all you have is a hammer.....

You can have a hierarchical type system without having "OO"... and, your error code approaches are essentially implementing type systems anyway, albeit in a roundabout and limiting way. Just because your language doesn't natively support it doesn't mean you can't create a proper type structure on your own -- all you really need is linked nodes that point to their "superclass" node.

DrPepper · 2014-03-07 Reply Admin

faoileag:
"There will one day be lemon-soaked paper napkins. Till then there will be a short delay. Please return to your seat."

Plus 1 for that!!!

chubertdev · 2014-03-07 Reply Admin

lolatu:
EvilSnack:
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.

I actually agree with you 100%. I use exception handling very rarely, and usually when I didn't write the class that throws the exception. I have written classes that throw exceptions, but only under the rarest of circumstances. 99% of the time I will do exactly what you suggest, return an error and do something else on that return.

With frameworks like .NET, you rarely need to throw exceptions. Maybe when you're creating something that another company will use, and you want to give them something meaningful. You're usually handling the exceptions that the framework throws. They're meant almost to be communication between code layers of different modules. To say things like, "hey dummy! that file that you're trying to read? it doesn't exist!"

SD123 · 2014-03-07 Reply Admin

Exceptions are for exceptional circumstances. They may be a language feature but their implementation is by design.

If I designed an object that loaded an entire file into memory I have two choices. Return an error or raise an exception. At the file level inside the object I need to return an error. Outside the object I'm likely to plump for an exception, otherwise you've constructed a useless object for which you need to call a method to see if it failed. Thus, inside the object I see the error & make a choice - raise an exception or not.

The design comes in here. Can I use an existing exception or do I implement my own?

For examples of the latter look no further than Delphi. For implementation problems look no further than raising an exception across threads.

By way of a simple example, if I were to write a 24/7 app I would not be using exceptions whereas if I were using the above mentioned "load all file into memory" object in a twiddly app I wouldn't be concerned if it raised "out of memory", dumped that on the console & stopped.

2014-03-08 Reply Admin

QJo:
chubertdev:
asdf:
chubertdev:
asdf:
else {throw;} - not else {throw hex;}

Six of one.

Sure, if you don't care about the whole stack trace and instead want to change where the error came from.

IMHO, I think that developers have become too dependent on the stack trace for exceptions.

That's like what one lungfish says to another lungfish: "IMHO, I think that land-dwellers have become too dependent upon legs for locomotion."

That lungfish's mind is still in the 1970s.

We're too dependent upon wheels and gasoline for locomotion nowadays.

Exceptional Recursion

Leave a comment on “Exceptional Recursion”