Phil Goodwin
Phil Goodwin[FrontPage] [StartingPoints] [RecentChanges] [CategoryPatternsGroup] [http://www.c2.com/cgi/quickChanges?days=1]
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]
I regularly attend the SiliconValleyPatternsGroup.
Favorite Wiki tricks:
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 PeopleProjectsAndPatterns... From the beginning wiki was intended to index itself. Or, more correctly, wiki visitors were supposed to evolve into VolunteerHousekeepers. This is one reason that RecentChanges has never automatically pruned itself. A variety of indexing innovations have been introduced and maintained by the community: RecentVisitors, PeopleIndex, NotSoRecentChanges?, ThreadMode, ThreadModeConsideredHarmful, WikiCategories, RoadMaps, ChangeSummary... 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. -- WardCunningham [from WikiHistory]
--
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. [WardCunningham from GoodStyle]
--
There are WikiMasters, 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 WikiMaster. Nobody who makes major changes without thinking carefully is a WikiMaster. One of the secrets of being a WikiMaster 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 WikiMaster 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 WikiMaster without changing what others have written. -- RalphJohnson [from WikiCreep (emphasis added)]
Interesting pages:
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 HomogenizeExceptionHandlers?) 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. (ThrowsExceptionByDefault)
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.
ObjectFunctionalPatterns Transactional Isolation is a key component to combining Object and Functional technologies. Read transactions that rely on LazyEvaluation 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.
EditText of this page
(last edited November 15, 2009)
or FindPage with title or text search