Page History

...

1. Never call methods that can be overridden by a subclass from the constructor.
   1. If you call any method from the constructor, either declare the whole class final.
   2. Or make method private, or final, or static.
2. Exceptions Handling
   1. Checked Exceptions
      1. Handle checked exceptions when possible.
      2. In case the exception cannot be handled, allow it to propagate to the calling method by declaring "throws".
      3. If the method's API cannot be changed, wrap the original exception with WebApplicationException. Important! Never wrap unchecked exceptions with WebApplicationException!
      4. The InvocationTargetException should always be handled. Consider using the following pattern:

         Code Block
         try { } catch (InvocationTargetException e) { Throwable targetException = e.getTargetException(); if (targetException instanceof RuntimeException) { throw (RuntimeException) targetException; } throw new WebApplicationException(targetException); }

   2. Unchecked Exceptions (Runtime Exceptions)
      1. Don't catch unchecked exceptions unless you can handle them properly.
      2. Be aware of "catch (Exception e)" statement, since it also catches unchecked exception. If there are multiple checked exceptions that should be handled in the same way, consider using the following pattern:

         Code Block
         try { } catch (RuntimeException e) { throw e; } catch (Exception e) { // handle exception here }

Logging

1. In general logging is a good idea.
2. Use Commons Logging Slf4j.
3. For debug messages, call if (log.isDebugEnabled()) prior to calling log.debug().
4. The following code is usually bad. There is no need to log exception and re-throw it:

   Code Block
   try { } catch (Exception e) { logger.error(e.getMessage(), e); throw new RuntimeException(e); }

   Either log it, or re-throw.

Logging Messages

1. Messages which are visible to the end user should have their strings externalized and read from a properties file to allow for easier NLS translation.
2. Debug messages do not need to be put into a properties file.

Formatting

In a perfect world all people, who contribute code, use the same IDE with the same formatting preferences which, for example, significantly reduces a number of redundant SVN merges.

1. An Eclipse code style is attached to this page: wink-eclipse-codestyle.xml Code contributions may use other format styles but please try to use at least the following rules.It should be a good idea to attach a formatter profile for Eclipse that contributors are expected to use.
2. Anyway for people, who don't use Eclipse, or want to keep their formatting preferences, let's define some basic rules:
   1. Do not use Tab. For indentation use only spaces. Indentation size is 4 spaces.
   2. Maximum line width: 100 characters.

...