| Summary: | [DB] Fetching non-existent CDOID from DBStore throws wrong exception | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Caspar D. <caspar_d> | ||||||
| Component: | cdo.db | Assignee: | Project Inbox <emf.cdo-inbox> | ||||||
| Status: | NEW --- | QA Contact: | Eike Stepper <stepper> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | saulius.tvarijonas, stepper | ||||||
| Version: | 4.13 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Note also (see stacktrace) that the exception thrown suggests that the specific problem is the absence of type information for that ID. In fact, there is simply no object by that ID at all. Perhaps the DBStore should catch and "translate" the exception. In any case, for a given scenario, the client should be presented with the same exception from all stores. (In reply to comment #1) > [...] In any case, for a given scenario, > the client should be presented with the same exception from all stores. +1 That reminds me to bug 336318... Not reproducible in 4.1. Created attachment 207402 [details]
Testcase (as patch)
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems. Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!! Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2. Moving all open bugzillas to 4.5. Moving all unaddressed bugzillas to 4.6. Moving all open bugs to 4.7 Moving all unresolved issues to version 4.8- Moving all unresolved issues to version 4.9 Moving to 4.13. |
Created attachment 207397 [details] Stacktrace Fetching a non-existent CDOID from MEMStore gives ObjectNotFoundException, which makes sense. Doing the same on a DBStore gives a RemoteException wrapping an ISE.