If there are special cases, they’d probably be handled differently in each of these strategies. For example, with self-logging exceptions, perhaps certain subclasses (e.g. checked exceptions in package com.foo.xyz) log themselves as warnings. Or one of the constructors allows you to pass in a log level.

In the end, I would look and say if some exception handling should be logged as a warning, should it really be treated as an exception? If so, implement a special strategy. If not, maybe use something else.

http://shortcut-finder.appspot.com/?query=eclipse

http://officeally.wordpress.com/

Trevor

Feature feature1 = new Feature(name, description, userId);

Ignore if this was nitpicking but do let me know if I am missing something here.

It would’ve been nice if final was the default in Java, and we could override this to make a method param “unfinal” in the rare case where we wanted to reassign it. Sigh.

I would suggest one more essential: documentation!

Using blocks to describe the meaning of elements is very helpful and very important.

For example, declaring an element named “weight” that contains an integer is insufficient in a schema, especially those that will be shared across business or business units.

Much more helpful is to document “the total shipping weight of the package, in pounds”.

What are the important elements to capture in schema documentation?
* Units of measure
* When the element is relevant or not relevant
* The semantic meaning of this element relative to others (e.g. “this date should always be prior to the transaction date”)
* How the information is to be interpreted
* Expected state transitions

This is another reason why enumerated types are so helpful, because you can document not only the possible values, but the precise meaning of those values and the expected transitions between them.