java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

	public  void someMethod sampleMethod() {
		try {
			someOtherMethod();
		} catch (Throwable ex) {
			throw new IllegalArgumentException(ex);
		}
		
	}
This does not compile because IllegalArgumentException class does not have
constructor
IllegalArgumentException(Throwable t) even thought it extends from
RuntimeException which does
(Review ID: 136600) 
======================================================================

Customer Workaround :
use
 throw (IllegalArgumentException)(new IllegalArgumentException().initCause(ex));
Note the cast is needed or javac complains about not declareing the Throwable
exception in the method header
======================================================================

Believe it or not, this was not an oversight.  When I designed the nested exception facility I thought carefully about which excpeptions should be given a (Throwable) constructor, and came to the conclusion that IllegalArgumentException did not need one, even though it is designed to be extended.  The rationale is that this constructor is designed specifically for use when an input parameter is invalid, not when some lower-level action fails (throwing an exception that demands nesting).  I understand that it's theoretically possible that such an exception is the direct result on an invalid parameter, but it appears impractical for a program to make that determination. 

When the chained excption facility was designed, I was unable to come up with a situation wherein a program would actually want to throw an IllegalArgumentException with a nested Exception.  I am marking this exception incomplete to give the reporter an opportunity to describe such an scenario.  Barring such a scenario, I believe this bug should be closed.

 xxxxx@xxxxx  2001-12-06

Here is a second secenario were chaining is deficent.

I have written a static method which catches exceptions 
thrown by a sub-thread and re-throws them in the main-
program thread.  Clearly this is a use for exception 
chaining.  But because InterruptedException can not be 
chained directly I have to use the above klug.  
I chose to chain to InterruptedException because that is 
what join() throws at the moment.  My static method 
replaces join().

I submit ALL exceptions should be chainable so as not to 
limit the usefullness of chaining.

Chaining works well giving outputs like
au.com.forward.ThreadException: Thread-3

	at au.com.forward.ThreadException.join
(ThreadException.java:118)

	at au.com.forward.ThreadException.join
(ThreadException.java:78)


	at 
au.com.forward.tests.ThreadExceptionTests.testThreadExceptio
n(ThreadExceptionTests.java:108)

	at au.com.forward.tests.ThreadExceptionTests.main
(ThreadExceptionTests.java:35)

Caused by: java.io.IOException: TestThread throwing 
IOException

	at au.com.forward.tests.TestThread.run
(ThreadExceptionTests.java:137)

Thanks for detailing your reasoning.
Imagine this method:

/**
Return the contents of the supplied URI as a String.
*/
String getAsString(String uri);

Granted, taking a URI as a parameter is probably a better
alternative, in general.  What if the method is called so
often that you want it to construct the URI and contain the
try/catch block?

Given the above declaration, I would want to rethrow any
checked URISyntaxExceptions
as unchecked IllegalArgumentExceptions.  In this case, it is
trivial to determine
that the exception is the direct result of an invalid parameter.

There are additional analogous situations, even if all
exceptions are limited to those in the JDK.  Limiting the
frame of reference to the JDK isn't the right approach.
Most sizeable, well designed, applications will define some
new exceptions.
The possibilty that none of these new exceptions would
substantially benefit
by allowing IllegalArgumentException to be chained seems far
more remote than the alternative.