java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, symcjit)

If I need to catch three exceptions, say, NamingException, CreateException and
RemoteException (all of which are descendants of java.lang.Exception) and if I
need to take the same action for them I should not be required to catch them
one after the other. Your compiler should allow me to do something like the
following:

Exception exc;
try
{
   //bunch of stuff
}
catch (NamingException, RemoteException, CreateException exc)
{
    exc.getMessage ();
}
(Review ID: 119838) 
======================================================================

N/A

I can see why someone would wish for this. However, this just a bit of fancy sugar, and not a very frequent problem. Nor is the burden on the programmer
very great: the common action can easily be encapsulated in a method. In most
cases, the multiple exceptions might well be organized in hierarchy with a
common superclass to avoid this problem. Of course, this might not always
be  possible. 

Altogether, an exceedingly minor problem. We'll take it under consideration.

  xxxxx@xxxxx   2001-03-30
Maybe.
Posted Date : 2007-01-19 23:33:09.0

Not a very nice solution in my opinion. It still forces the 
use of repeated code (the calls to the exception handler).

I like it the ADA way, where you can specify the differrent 
exceptions and handle them in a common way.

This should be a language feature, it really does help to solve problems with code correctness and code reduction.

With regards to "the common action can easily be encapsulated in a method", this is in general not true if the common action involves assigning to a number of local variables, as has been the case in a number of instances of this I have seen.

I think this would be really useful. A typical situation where I wished this feature existed: you have a piece of code that uses reflection *and* performs some other operations.
All reflection-related exceptions (NoSuchMethodException, InvocationTargetException, etc.) usually indicate either a programming error or a severe installation/configuration mistake... you usually want to re-throw them wrapped in some fatal runtime exception. Other exceptions are possible and must be handled in some layer of the application.
If every exception hierarchy was perfectly designed, there would probably be no need for this, but as a designer I know too well that exceptions are perhaps the hardest part of a design...

This is not "an exceedingly minor problem", but the single most irritating issue in the entire language!  If the code is 2-3 lines of code it's not worth creating a method for it, but this can still create 50 lines of code if there are ten different exceptions to catch.  This is especially relevant where there are many different types of failure cases which should be distinguished, in which case an exception hierarchy doesn't help.  There are also lots of cases in the JRE itself where a suitable hierarchy does not exist (such as reflection mentioned above)!

Relating to the implementation, within a "catch (AException, BException e)", e should be of the most specific common supertype of AException and BException.  However, a "throw e" command should take into account that e can only be of types AException and BException.  This would allow writing for example

catch (AException, BException, CException e) {
    log("Error: " + e.getMessage());
    throw e
}

without losing the exception type information.

PLEASE take this into serious consideration!

See also comments on RFE #4909760 for more use cases where this would be necessary.