Home Help Center

Best practice for exception mapping

HpGislerHpGisler Member Hanspeter GislerOrganization: SensirionProject: Rigi
Hello

I've got a basic question regarding the usage of exceptions. Probably, it's a little naive anyway.

Ok.

Here is the situation:

We've got a C++ server side application and a C# client side application.

For error handling, we defined in slice some exceptions which can be thrown by the server side application and which can be catched by the client side application.

We are interested in a simple text based info in these exceptions, so we've added a string property into the slice exception definition accordingly.


Now to the question:

In the end, we simply would like to put the error-string into a standard C#-base-type-exception.

Is the manual wrapping of each proxy-method-call into a try-catch statement the only reasonable way to get the string out of the ice-exception and into a client side exception (re-throwing it in the catch clause), or is there a more elegant way to achieve this?


Thanks very much for your professional inputs. :o

Regards
hp.

Comments

  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    Hmmm, let me make sure I understand you correctly. You have a Slice exception that is thrown by an operation. When the exception is thrown, you don't want the Slice exception to propagate higher up the call stack. Instead, you want to throw a different exception, not defined in Slice. Something like:
    try {
        proxy.operation();
    } catch (SliceException) {
        throw new NonSliceException();
    }
    
    You also say that the Slice exception contains an error string that you would like to be in the non-Slice exception. Something like:
    try {
        proxy.operation();
    } catch (SliceException ex) {
        throw new NonSliceException(ex.text);
    }
    

    As you can see, whether the string is there or not makes little difference. The only way to "translate" one exception into another is to catch the exception and throw a different one, which requires try-catch blocks.

    You need not necessarily do this for every invocation. Instead, you can most likely install the try-catch blocks higher up in the call hierarchy and deal with the exception there, so you do not clutter the code with endless identical try-catch blocks. But, somewhere, you will need to do this in order to throw a different exception than is received over the wire.

    Cheers,

    Michi.
Sign In or Register to comment.