Task #102 (closed)
Opened 18 years ago
Closed 12 years ago
InternalException and getCause()
Reported by: | cxallan | Owned by: | cxallan |
---|---|---|---|
Priority: | minor | Milestone: | Unscheduled |
Component: | API | Version: | 3.0-M2 |
Keywords: | n.a. | Cc: | |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
Currently InternalException? gives you no way of accessing the wrapped exception that was thrown. Is it possible to use the getCause() methods of Java RuntimeException? to do so?
Change History (5)
comment:1 Changed 18 years ago by jmoore
comment:2 Changed 18 years ago by jmoore
- Keywords iteration2 removed
comment:3 Changed 18 years ago by jmoore
- Milestone changed from 3.0-M2 to Unscheduled
- Owner changed from jmoore to callan
Moving to Unscheduled, though.
Discussion is in your hands, Mr. Allan.
comment:4 Changed 12 years ago by jburel
Could we close that one?
comment:5 Changed 12 years ago by cxallan
- Resolution set to wontfix
- Status changed from new to closed
We now have limited versions of this working with stringified server side stack traces only. It is dangerous to ever be sending server side stack traces with classes to the client as this is highly dependent on the client side CLASSPATH. Closing as wontfix.
This is a tricky issue. Originally it was so planned that getCause would return a non-null, but it's difficult to know what Classes the client will have. If the cause is, for example, a Hibernate exception, then on de-serialization, the client gets an unrelated IO exception. We could discuss strategies, such as keeping all Java native exceptions (java.lang.* etc.) but for the moment the most complete fix was to not use Throwable#cause.