Exceptions vs defensive programming

Question

Hi...
Which of the following two code fragments is 'better'... bearing in mind that Java's exception handling syntax is commonly touted as aiding readability, allowing programmers to focus on the 'task' rather than a nest of 'if' statements and suchlike? I'm just askin' outta interest's sake...
Fragment 1...
public void actionPerformed (final ActionEvent e) {
     if (_target != null && _clipboard != null) {
          Transferable clipContents = _clipboard.getContents (null);
          if (clipContents != null) {
               if (clipContents.isDataFlavorSupported (DataFlavor.stringFlavor)) {
                    try {
                         String contents = (String) clipContents.getTransferData (DataFlavor.stringFlavor);
                         if (_target.getSelectedText () != null) {
                              //replace the selection with the contents of the clipboard
                              _target.replaceSelection (contents);
                         else {
                              //insert the contents of the clipboard ahead of the current insertion point
                              int insertionPoint = _target.getCaretPosition ();
                              _target.getDocument ().insertString (insertionPoint, contents, null);
                    catch (final BadLocationException ble) {
                         //bleep! **((*!@4%@!! :D
                         Toolkit.getDefaultToolkit ().beep ();
                    catch (Exception ignoredForNow) {}
}Fragment 2...
public void actionPerformed (final ActionEvent e) {
     try {
          Transferable clipContents = _clipboard.getContents (null);
          if (clipContents.isDataFlavorSupported (DataFlavor.stringFlavor)) {
               String contents = (String) clipContents.getTransferData (DataFlavor.stringFlavor);
               if (_target.getSelectedText () != null) {
                    //replace the selection with the contents of the clipboard
                    _target.replaceSelection (contents);
               else {
                    //insert the contents of the clipboard ahead of the current insertion point
                    int insertionPoint = _target.getCaretPosition ();
                    _target.getDocument ().insertString (insertionPoint, contents, null);
     catch (final BadLocationException ble) {
          //bleep! **((*!@4%@!! :D
          Toolkit.getDefaultToolkit ().beep ();
     catch (final NullPointerException npe) {
     catch (Exception ignoredForNow) {}     
}

Answer 1

I totally disagree with not having more than one return statement.
I have had to maintain code like this and it is a total mess:
    boolean continue = true;
    int a = getSomeInfo();
    continue = someCheck(a);
    if (continue) {
        // do some stuff with a
        continue = someCondition();
    if (continue) {
       // do some other stuff with a
       continue = anotherCondition();
    //etc.
    return a;
}The problem with this is really hard to detemine what gets returned when you try to read the code. I think the idea that one exit point in a function makes things more simple is total crap. Sometimes it is better but I'd rather see this.
    boolean continue = true;
    int a = getSomeInfo();
    if (someCheck(a)) return a;
    // do some stuff with a
    if  (someCondition()) return a
    // do some other stuff with a
    if (anotherCondition()) return a;
    //etc.
    return a;
}This way you at least have the compiler on your side helping you make sure your conditions are reachable and so forth. Also, in any decent editor keywords like return are easy to spot and therefore are easier to see than a = something(). The idea of a single exit point was very valid before try catch finally, it helped make sure clean up was done. With finally you can forget that rule.
Here's another good example where one exit point can be a pitfall.
public String method(int value){
   String returnString;
   switch (value) {
      case 1:
         returnString = "one";
         break;
      case 2:
         returnString = "two";
      case 3:
         returnString = "three";
    return returnString;
}There are two major problems with this code that may not be immediately obvious (more so in a more realistic and complicated example.) 1. If the value entered is not 1, 2 or 3 the method returns null (which you may or may not want.) 2. if the user enters 2 the result will be "three"
Now if you use multiple returns both of these problem are non-existant
public String method(int value){
   String returnString;
   switch (value) {
      case 1:
         return "one";
      case 2:
         String returnString = "two";
      case 3:
         return "three";
}Problem 1 will now cause a compiler error because not all paths of the method return a value.
Problem 2 will cause the same error because you are not returning anything for 2 and there is no return statement after the switch.