A DESCRIPTION OF THE REQUEST :
The try-catch block encourages programmers to large segments of code in the try block for proper execution flow. However, this leads to inefficient and incorrect error handling. The other method is to watch for side-effects after the try-catch block has execution, but this leads to code that is more error prone.

JUSTIFICATION :
Suppose you have three methods:

1. void foo() : Contains a try block that calls bar and qux.
2. Object bar() throws Exception : Returns input necessary for qux.
3. void qux(Object input) : Process input returned from bar.

There are two solutions to the above situation. The first is problematic, yet typical:

void foo () {
    try {
        Object result = bar();
        qux(result);
    } catch (Exception e) {
        System.err.println("C'est la vie.");
}

Object bar() throws Exception {
    if (Math.random() < .5) {
        throw new Exception("Oops!");
    }
    return new Object();
}

void qux(Object input) {
   System.out.println(input);
}


The above solution has the following problems:

1. The call to qux does not need to be, and therefore should not be surrounded by a try-catch block.
2. If qux is altered to throw the same type of Exception that bar throws, foo must be altered to handle errors from both methods.

The second solutions doesn't have any of the above problem, yet litters the code with programmer derive flow-control logic:

void foo () {
    Object result = null;

    try {
        result = bar();
    } catch (Exception e) {
        System.err.println("C'est la vie.");
    }
    
    if (result != null) {
        qux(result);
    }
}

Even though this solution is better, it's prone to programmer error. Simply changing != to == or result to some other varible in the if-statement renders the code broken.

Seeing no other way to get around this issue, I hereby propose a new addition to the try-catch block:

void foo() {
    Object result;
    
    try {
        result = bar();
    } do {
        qux(result);
    } catch (Exception e) {
        System.err.println("C'est la vie.");
    }
}

This method has all of the following advantages:

1. Exception throwing code is correctly separated from code that doesn't throw any exceptions.
2. There is no programmer defined flow control, everything is built into the language.
3. The pre-existing do keyword is used, so backward compatability is preserved.

Please consider it for inclusion in the next release of the Java language.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
See Justification.
ACTUAL -
See Justification.

---------- BEGIN SOURCE ----------
See Justification.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
See Justification.
###@###.### 2004-12-30 06:11:15 GMT