Issue withTomcat shutdown.sh leaves server running

Those of you lucky enough to own a Sinclair Spectrum will remember the joys of popping your favourite game into the cassette player and then sitting back to watch the stripy colours flashing while the game loads. Sometimes after waiting 5 – 10 minutes you’d be presented with the words….
R Tape loading error, (0:1)
You can now relive this experience online over at http://www.rtapeloadingerror.com/, albeit without tape loading and 5 – 10 minutes waiting time.


Don’t have a clue what I’m talking about? Shame on you! Head over to these links to find out more:
http://en.wikipedia.org/wiki/ZX_Spectrum
http://www.worldofspectrum.org/

Click here to View more...

Pass all relevant data to Exceptions in Java

When an exception occurs, it is important that all pertinent data be passed to the exception's constructor. Such data is often critical for understanding and solving the problem, and can greatly reduce the time needed to find a solution.

The this reference is sometimes useful for this purpose, since toString is implicitly called. In addition, if you are defining exception classes yourself, you may even design your constructors to force the caller to pass the pertinent data.

Uninformative stack traces are very frustrating for the maintainer, and often inspire even the most well-tempered programmers to temporarily violate local community standards for obscenity.

Example

public final class RangeChecker {

  /**
  * Return true only if aNumber is in the range
  * aLow..aHigh (inclusive).
  *
  * @param aLow less than or equal to aHigh.
  */
  static public boolean isInRange( int aNumber, int aLow, int aHigh ){
    if (aLow > aHigh) {
      throw new IllegalArgumentException("Low:" + aLow + " greater than High:" + aHigh);
    }
    return (aLow <= aNumber && aNumber <= aHigh);
  }
} 

Effective Java mentions IndexOutOfBoundsException as a counter-example. This exception does not provide information regarding the relevant indexes, which would often be useful for solving the problem :

• the offending index value
• the minimum and maximum permitted index values

Click here to View more...

When to use What - try / catch / finally in Java

The finally block is used to ensure resources are recovered regardless of any problems that may occur.

There are several variations for using the finally block, according to how exceptions are handled. (See the excellent book The Java Programming Language by Arnold, Gosling, and Holmes for related information.)

Situation 1

If a method throws all exceptions, then it may use a finally with no catch 

Situation 2

If a method handles all exceptions, then an interesting variation is to nest a try..finally within a try..catch. This style is particularly useful when the finally block throws the same exceptions as the rest of the code (which is common with java.io operations.) Although this style may seem slightly complex, it appears to be superior to alternative style 

Situation 3

A more verbose style places a catch within the finally. This style is likely the least desirable, since it has the most blocks

Click here to View more...

Avoid empty catch blocks in Java

Most contend that it's usually a very bad idea to have an empty catch block.

When the exception occurs, nothing happens, and the program fails for unknown reasons.

In general, when a exception occurs, it can be thrown up to the caller, or it can be caught in a catch block. When catching an exception, some options include :

• inform the user (strongly recommended)
• log the problem, using the JDK logging services, or similar tool
• send an email describing the problem to an administrator

Deciding what exactly to do seems to depend on the nature of the problem. If there is an actual bug in the program - a defect that needs to be fixed - then one might do all three of the above. In this case, the end user should likely be shown a generic "Sorry, we goofed" message, not a stack trace. It is usually considered bad form to display a stack trace to a non-technical end user, or if exposing a stack trace may be a security risk.

If the exception does not represent a bug, then different behavior may be appropriate. For example, if a problem with user input is detected and an exception is thrown as a result, then merely informing the user of the problem might be all that is required. For example, a message might read :

Cannot connect to database.


Example
The "tried our best" comments below are an example of what not to do :

import java.io.*;
import java.util.*;

/** How NOT to implement a catch.  */
public final class BadCatch {

  public static void main( String... arguments ) {
    List quarks = Arrays.asList(
      "up", "down", "charm", "strange", "top", "bottom"
    );   

    //serialize the List    try {
      ObjectOutputStream output =  new ObjectOutputStream(
        new FileOutputStream("quarks.ser")
      );
      try{
        output.writeObject(quarks);
      }
      finally{
        //flush and close all streams        output.close();
      }
    }
    catch(IOException exception){
      //TRIED OUR BEST    }
  }
} 

Click here to View more...

java.lang.NoClassDefFoundError: javax/servlet/jsp/el/ELException

SRVE0026E: [Servlet Error]-[javax/servlet/jsp/el/ELException]: java.lang.NoClassDefFoundError: javax/servlet/jsp/el/ELException
at java.lang.Class.getDeclaredMethods0(Native Method)

Solution:

You need the jstl.jar and standard.jar on the webapp's classpath.
You can get them from the jakarta site.
Click here to View more...