Description Martin Oberhuber 2009-08-07 09:09:19 EDT

+++ This bug was initially created as a clone of Bug #226374 +++

In bug 226374, we introduced some new default SystemMessageException children for general situations (such as network I/O problem) that can occur in any subsystem. RemoteFileSecurityException was deprecated at that time, in favor of the new SystemRemoteSecurityException which is generic and doesn't cover files only.

Problem is that as of today, in RSE we have *no single use* of SystemRemoteSecurityException, but 33 occurrences of RemoteFileSecurityException (not counting comments and import statements).

Existing service implementations throw that exception to indicate issues such as cannot write file / cannot create folder, and - more importantly - framework code checks for that particular kind of exception to test such special conditions.

In other words, clients which do migrate to the newer SystemRemoteSecurityException class are at risk of not being handled properly by the framework; and, if our services start throwing SystemRemoteSecurityException rather than the existing RemoteFileSecurityException, we are at risk of client software not understanding the errors that we throw properly.

Suggested Solution:
-------------------
In order to ensure compatibility, we need to be able to handle the older and newer exception kinds semantically the same way. I therefore propose creating a new interface - ISystemRemoteSecurityException - which is implemented by both the older and the newer concrete exception class. That way, our framework code can check for the interface and thus treat both exceptions the same way.

I think we also need to accept the fact that IRemoteFileSecurityException is a de-facto standard out there so we cannot remove it easily. At least as of today (RSE 3.1), clients are better off throwing the old one than the new one, since the new one is nowhere handled. I'm thus afraid we'll need to un-deprecate it, unless somebody has a smart idea how to deal with exceptions in a compatible way.

Time Plan:
----------
In order to show what we're up to, I propose un-deprecating RemoteFileSecurityException in 3.1.1 already. For the improved solution using a common API Interface, we'll need until we can add API in 3.2.

Comments welcome...