Task #102 (closed)
Opened 13 years ago
Closed 7 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 13 years ago by jmoore
comment:2 Changed 13 years ago by jmoore
- Keywords iteration2 removed
comment:3 Changed 13 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 7 years ago by jburel
Could we close that one?
comment:5 Changed 7 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.
Note: See
TracTickets for help on using
tickets.
You may also have a look at Agilo extensions to the ticket.
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.