Comments for Little Tutorials

Comment on Exceptional Java - Exception design relativity by Michael Haggerty

Michael Haggerty — Thu, 28 Aug 2008 08:03:03 +0000

Approach 2 is not a solution because it contains a race condition. Another thread could lower the customer’s account balance between the times that hasFunds() and transferFunds() are called. The check-and-transfer-funds sequence should be made atomic to avoid the need for external locking.

Comment on Bad advice on exceptions from Joel by Jeremiah Morrill

Jeremiah Morrill — Wed, 27 Aug 2008 23:18:13 +0000

Dijkstra wrote that GOTO opinion piece in 1968, when use of the GOTO statement was overabundant and did cause a mess. Today, using the GOTO statement is quite acceptable and will even find its usage in things such as the Linux kernel.

When used right, GOTO statements are much more readable than any alternative I can think of. I’d never give it up.

-Jer

Comment on Bad advice on exceptions from Joel by Wynand Winterbach

Wynand Winterbach — Wed, 27 Aug 2008 12:21:54 +0000

Damnit. I wrote “not everyone is a clueless [programming language name] basher”, but with angle brackets and it got nuked :).

Comment on Bad advice on exceptions from Joel by Wynand Winterbach

Wynand Winterbach — Wed, 27 Aug 2008 12:20:22 +0000

@Ben, Stephen wasn’t deliberately attacking C++. He has a point: out of all the existing C++ code bases, very few pervasively use smart pointers or the STL. Give more credit to other people; not everyone is a clueless basher.

Comment on Bad advice on exceptions from Joel by Wynand Winterbach

Wynand Winterbach — Wed, 27 Aug 2008 12:12:26 +0000

@Imp: I just realized you said everything I’m about to say, but more eloquently. But since I spent my lunch hour walk thinking about this, I’m posting my reply anyway.

If an exception it thrown, 9 times out of 10, it’s because something went wrong in your program. When this happens, I want all the state changes that occurred to be rolled back.

If you catch an exception far away from the point at which it was raised, it means that the methods in between had no interest in handling it. There are two cases where this would hold:
1. either the methods are executing additional code for side effects, or
2. the methods are computing some values to return in addition to the value computed by the method which raised the exception.

I try to avoid case 1, since this would leave the program with a possibly incomplete state change. Case 2 is a possibility, but in that case you should rather be returning an error code or something like Haskell’s Maybe - such a return value could be checked by one of the in between methods to decide whether to continue computing an additional return value or to abort.

Comment on Bad advice on exceptions from Joel by Ben

Ben — Tue, 26 Aug 2008 14:40:07 +0000

Saying don’t use exceptions in C++ because it doesn’t have garbage collection is just FUD. Anyone saying that either doesn’t code C++, or codes C and calls themselves a C++ programmer.

If you can’t handle smart pointers, STL containers or ptr container wrappers (either your own or from the boost library) and the like, then just stick to a garbage collected language, but please just leave C++ out of it as you clearly have no idea what you are talking about.

Comment on Code review - The meaningless ritual by Deepak

Deepak — Mon, 25 Aug 2008 22:00:40 +0000

I have a similar position on coding standards. If there was a way to count them, then I assume that there could be millions of coding standard documents on the planet. Most of these say the same thing such as how should curly braces be written.

Coding standards should be just plain old common sense. But then again it is the least common of senses

Comment on Software development dogmata - good practices gone bad by kapanpun

kapanpun — Mon, 25 Aug 2008 19:57:02 +0000

his article is spot-on. Software development is a craft, not a science, nor is it a manufacturing process. Software ‘Engineering’ is a misleading term. Building software is not like building a bridge. There are no silver bullets. No single methodology is ever going to cover all the software development cases. There are simply too many different environments for which software is built.

Comment on Bad advice on exceptions from Joel by Stephen

Stephen — Mon, 25 Aug 2008 11:53:52 +0000

Actually, Joel is right on the money.

This is mostly because of the lack of garbage collection in C++, there are too many ways to make mistakes with exceptions.

Error codes are of course bad, but they are the least bad choice.

Comment on Script Thy Java App by Tomek

Tomek — Mon, 25 Aug 2008 11:36:47 +0000

nice tutorial, thanks

but a counter class should rather have increment() method - using setter (counter.set(i+1)) smells like rotten JavaBean, uh, ugly smell, uh…

cheers
Tomek