Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Abi 2000
Stargate: Resurgence
Lost? Site Map!
     home | blog | moose | programming | articles >> blog

 Blog Topics

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 iTunesCantComplain released
2011-10-28 @954
 Dennis Ritchie deceased
2011-10-13 @359
 Thank you, Steve.
2011-10-06 @374
 Cocoa Text System everywhere...
2011-03-27 @788
 Blog migration
2011-01-29 @520
 All you need to know about the Mac keyboard
2010-08-09 @488
 Review: Sherlock
2010-07-31 @978
 Playing with Objective C on Debian
2010-05-08 @456
 Fruit vs. Obst
2010-05-08 @439
 Mixed-language ambiguity
2010-04-15 @994
 Uli's 12:07 AM Law
2010-04-12 @881
 Uli's 1:24 AM Law
2010-04-12 @874
 Uli's 6:28 AM Law
2010-04-12 @869
 Uli's 3:57 PM Law
2010-04-12 @867


Hungarian Notation good, Exceptions bad?

Joel Spolsky wrote a nice article about the merits of Hungarian Notation and the downsides of Exceptions. While I mostly agree, His solution is only the first step along the path. The solution is not to use Apps Hungarian from now on and to abolish Exceptions. The solution is to fix these problems in the languages.

For example, Apps Hungarian fixes a problem with the data type hierarchy in most programming languages. We need a way to say: You can't turn a value of type XCoordinate into a value of type YCoordinate even though they are both subtypes of ints. Once we have that, we don't have to manually read prefixes, we can let the computer check our types. It's the very same problem the introduction of typed parameters to C solved ages ago.

Similarly, there are ways to solve the problem with skipping code that needs to run even when an exception is thrown. C++ attempts this through having stack objects whose constructor and destructor perform allocation/cleanup of resources. Stack objects are destructed even when an exception is thrown. Objective C has autorelease pools that can be used to similar effect.

Of course, this requires you to design differently. Instead of (C++-like pseudocode):

char* foo = malloc(50)maypossiblythrow( foo )free( foo )foo = NULL
you need to write:
auto_ptr<char>   foo = malloc(50)maypossiblythrow( foo )
I'm not saying this is the best solution, but it is one, and it is also fairly easy to spot. Not to mention it's less lines of code, which typically endears any solution to us lazy programmers.

But Joel probably didn't mention this because he already saw the flaws: It's easy to overlook one of these balanced cases and just forget to write a class to handle it on construction/destruction. And there are cases where we only want our object disposed on exceptions, but on success one of the skipped functions will take over ownership of the memory. It's easy to miss those and leak an object, or overcompensate and get a zombie. Garbage collectors could be used to solve this, but they're not a good fit for all platforms (e.g. some embedded and realtime systems). Sometimes you just have to compromise, and then Joel's suggestion to just drop exceptions as well is a good idea.

As always, it boils down to knowing both the advantages and the disadvantages of each tool you're using, and to choose based on your current project, not based on personal preferences. This includes undesired interactions, and knowing that separates a programmer from someone who has learned a programming language.

Created: 2005-05-14 @886 Last change: 2005-05-14 @905 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.