[Front Page] [Starting Points] [Recent Changes] [Category Patterns Group] http://www.c2.com/cgi/quickChanges?days=1 www.c2.com
I live in Sunnyvale CA and can be reached via email at: mailto:phil.goodwin@sbcglobal.net
You can find out more about me at: http://www.linkedin.com/in/philgoodwin www.linkedin.com
I regularly attend the Silicon Valley Patterns Group.
Favorite Wiki tricks:
Title Search:
[Search]
Full Search:
[Fullsearch]
c2.com 
-- Make a cookie that sets user name in Recent Changes
c2.com -- top 10 read pages
You can leave me a message here:
Wiki quote collection:
This is the first ever wiki site, founded in 1994... [t]he site was, and remains, dedicated to People Projects And Patterns... From the beginning wiki was intended to index itself. Or, more correctly, wiki visitors were supposed to evolve into Volunteer Housekeepers. This is one reason that Recent Changes has never automatically pruned itself. A variety of indexing innovations have been introduced and maintained by the community: Recent Visitors, People Index, Not So Recent Changes, Thread Mode, Thread Mode Considered Harmful, Wiki Categories, Road Maps, Change Summary... I have done my best to discourage dialog in favor of disertation which offers a better fit to this medium. I've been overruled. I have always and will continue to make small edits to any page for the sake of brevity, clarity or decorum. I encourage others to do likewise. -- Ward Cunningham [from Wiki History]
--
Good Style
Write factual information. Give concrete advice. Use second or third person when possible as this makes editing and elaboration easier. Write and sign first person accounts when reporting experience not easily reduced to facts or advice.
Place words where they are easy to read, which isn't always at the bottom. Edit pages to emphasize the flow of ideas, not the chronology of contribution... Finally, don't say things designed to make others mad. Practice civility and understatement. You will reach ten times as many readers even if you miss the ones you want to zing. [Ward Cunningham from Good Style]
--
There are Wiki Masters, and I believe I am one. I have been anonymously editing pages since the first year of wiki and nobody has ever complained. I have never criticised anybody anonymously. In fact, I rarely criticise anybody in public. If the message is signed, then I respond by e-mail. If it is not signed, I wait a week and then if I still think it is necessary, I refactor. "Refactor" does not mean "delete"! Nobody who makes anonymous criticisms is a Wiki Master. Nobody who makes major changes without thinking carefully is a Wiki Master. One of the secrets of being a Wiki Master is doing as little as possible to achieve maximum effect.
"Noise" means things that are not interesting. I have a wide tolerance for noise. I find most of the eastern philosophy that has been a part of wiki from the beginning to be "noise". But in the past, most pages in recent changes were about software. Now most of them are not. To me, the signal to noise ratio has gone down dramatically. In this situation, a Wiki Master will avoid touching pages that are just noise, and will look for old pages that are full of signal and touch them to bring them to the top again. There are many ways to be a Wiki Master without changing what others have written. -- Ralph Johnson [from Wiki Creep (emphasis added)]
Interesting pages:
Category Object Functional Patterns and Functional Programming:
Functor Object Function Call Object Command Query Separation Fp Vs Oo Function Object Pattern Functional Pattern System For Object Oriented Design Generic Function Higher Order Function Lambda Calculus Translator Pattern
Category Cpp:
Alternatives To Cee Plus Plus Extreme Cpp Form Example Extreme Cpp Form Test Extreme Forms For Cpp Code Extreme Guidelines For Cee Plus Plus Extreme Guidelines For Cee Plus Plus Discussion Initialization Is Resource Acquisition Redundant Include Guards Refactoring Cpp To Reduce Dependencies Resource Acquisition Is Initialization Use Const Member Functions Using Templates
Java:
Future Of Java Ideal Java Editor Java Doesnt Pass By Value Java Passes By Value References Values Identities And Variables Return New Objects From Accessor Methods Alternatives To Pass By Reference
Exception Patterns:
Avoid Exceptions Whenever Possible Catch What You Can Handle Checked Exceptions Are Of Dubious Value Code Without Exceptions Designing With Exceptions Convert Exceptions Do Not Use Assertions Dont Throw Generic Exceptions Exceptions Cancel Operations Homogenize Exceptions Illuminate The Mainline Java Exceptions Are Particularly Evil Let Exceptions Propagate Throw Dont Catch Throws Exception By Default What Are Assertions Category Exception
Coding Standards:
Braces Are Good Braces Around Blocks Hungarian Notation Methods With Noun Names
General Programming / patterns / principles:
Critique Of Use Cases Design By Contract Distributed Objects Null Object Null Object For Every Class Open Closed Principle Package Design Requirements And Design Value Object Value Objects Can Be Mutable Whatsa Controller Anyway When Is Manifest Typing Considereda Good Thing Principles Of Object Oriented Design
XP:
Code Normalization Cthree Project Terminated Dealing With Cumbersome Environments Extreme Coding Standards Extreme Hour Extreme Misunderstanding Is Xp Synergistic Silicon Valley Extreme Hour Spike Described Xp And Post Modernism Xp Immersion Two
Unit Testing:
Cpp Bridge Enhancing Cpp Unit Enhancing Junit Java Ui
Category Wiki Maintenance:
Volunteer Housekeeper Convert Thread Mode To Document Mode Refactor By Condensing Question Answer Pair Refactor By Extracting To Page Refactoring Wiki Pages Refactor While Respecting Signatures Therefore But Summaries On Top Discussion Below Wiki Page Layout How To Write And Edit Thread Mode Using Signatures
Economics:
Internet Economy Of Credibility Network Externalities Patents Are Evil, Economics keeps US running.
Books:
Large Scale Cpp Software Design Pragmatic Programmer Refactoring Improving The Design Of Existing Code The Manufacturing Of Consent
Misc:
Binary Search In Java Test Masking Interfaces Myers Briggs Of Course Im Probably Wrong Programmers Notebook Programmers Thesaurus Survival Of The Fitters Test Null Tips From Ward Cunningham Uml Considered Harmful What Makes Discussion Groups Effective Six Thinking Hats
Wiki Things I want to do:
Pages I want to write:
Pages in progress
Notes
Exceptions
From otug
Checked exceptions in Java create a dependency between a throwing method and all of its callers. That's a very steep price to pay for a service and, as it turns out, the service provided by checked exceptions isn't terribly valuable. What you get is documentation about the types of exceptions that can propagate. That may seem like a good thing but in practice all the non-handling code needs to know is that some kind of exception can propagate. The exception handling code usually doesn't need the type information either but if it does it can be retrieved by having multiple catch clauses. Non exception handling clients benefit from knowing when a method they are calling can throw so that they can clean themselves up before allowing the exception to propagate. So the type information in the "throws" clause of a method declaration only serves two purposes: as documentation about what sort of exception handlers to write in the rare case that types of exception need to be distinguished and as a notification that an exception can propagate out of the method.
(for Homogenize Exception Handlers) In my experience exception handlers are rare. They appear either very close to the UI or very close to some sort of system boundary that requires error information to be marshaled. My experience has been the longer the distance between the thrower and the handler the greater the chance that exception handling is the correct error handling strategy. My experience is also that all of the handlers implement the same error handling strategy - usually by calling some function that does the actually handling. What this indicates is that the best strategy for writing exception handlers is to devise a strategy for handling each type of exception (preferably with most types handled in a single, uniform, way) and then implement that strategy in every handler throughout the system without regard to the types of exception that a particular handler can be expected to be exposed to. The advantage of this strategy is that it provides a single, coherent, strategy for exception handling. Both the exception handlers and the exception throwers are coupled to the pool of available exception types (a fairly stable abstraction) but not to each other. The disadvantage is some duplicated code in all of the handlers. In practice this code is easy to maintain because it is fairly stable and easy to find.
Methods that contain exception handlers aren't the only ones that need to be aware of propagating exceptions. A propagating exception is equivalent to aborting a database transaction. All the work done starting from the initial call in the "try" clause up to the point of the exception throw should be rolled back to its initial state, or in the worst case rolled forward to some stable state. In order to write code that is exception safe an author needs to know which methods might throw exceptions, so that the rollback code can be put into a finally clause, and, which methods cannot throw exceptions and are therefore safe to call after rollback becomes impossible. The latter sort of methods are critically important to writing correct programs. It would be a grave error to create a method that doesn't throw exceptions, use it in a situation where exceptions aren't tolerated, and then change it so that it does throw an exception. (Throws Exception By Default)
Based on this analysis this is the strategy that I use and recommend for exception handling in Java: declare every method with "throws Exception" as the default. Methods that MUST NOT throw exceptions are declared without a "throws" clause (if it were my language to write you'd have to specify something special for a method that DOESN'T throw rather than one that does). If I need something more specific than "throws Exception" then I put it in - it hasn't happened yet so I can't be more specific. If it happens that a method doesn't actually propagate any exceptions and I need to use it in a situation where it won't be allowed to then I remove the "throws Exception" clause. Having to rewrite a non "throws Exception" method so that it does throw is a big deal because all of its clients have to be checked and possibly rewritten.
My exception handlers almost always either translate the exception into some other form of error for further propagation or they ask the end user to make a decision about how to proceed. I anticipate that, on occasion, I'll write exception handlers that try an alternate strategy to accomplish the original task, but I have not yet had the opportunity to do so.
Object Functional Patterns Transactional Isolation is a key component to combining Object and Functional technologies. Read transactions that rely on Lazy Evaluation must be isolated from write transactions that operate on the same data. That suggests that laziness shouldn't be allowed to cross transaction boundaries and that lazy reads should always be made against pre-transaction data. For instance: in the game of life the data from all the cells must be read and processed before any of the cells is allowed to change. If we use lazy-evaluation of cells instead then we must ensure that we read the state of each cell before it changes. That means that after every write we must end up with two copies of the data - pre-write and post-write - and we must maintain both copies until we commit. We have to do that anyway in order to get rollback semantics.
Transactional programming Durability: when transactions are nested then the results of a sub transaction must be durable with respect to it's parent transaction.
See original on c2.com