Rethrown custom exception behaving badly from Out-of-process compo

[Guest]

I am catching an exception in a class derived from ServicedComponent
(original exception being thrown from class the does NOT inherit from
ServicedComponent) and rethrowing a custom exception
(ARSApplicationException), including the original exception in the custom
exception.

If another application receives the exception from the ServicedComponent,
they get the custom exception message, but do not get the custom
ARSApplicationException and do not get access to the Inner Exception.
Instead they get an ApplicationException - which ARSApplicationException
inherits from

Here is the code (which is executed) from the ServicedComponent class:

Try
....
Catch ex As Exception
Throw New ARSApplicationException("The zonal analysis properties could
not be mapped from the database", ex)
End Try

Here is the ARSApplicationException code:

Imports System.Runtime.Serialization
Imports System.Text

<Serializable()> _
Public Class ARSApplicationException
Inherits ApplicationException

Public Sub New(ByVal Message As String)
MyBase.New(Message)
End Sub


Public Sub New(ByVal Message As String, ByVal InnerException As Exception)
MyBase.New(Message, InnerException)
End Sub

Public Sub New(ByVal Info As SerializationInfo, ByVal Context As
StreamingContext)
MyBase.New(Info, Context)

End Sub

Public Overrides Function ToString() As String
Dim objSB As StringBuilder = New StringBuilder(Me.Message)

If Not Me.InnerException Is Nothing Then
objSB.Append(" - ")
objSB.Append("Inner EXception message: " & Me.InnerException.Message)
End If

objSB.Append(vbCrLf & Me.Source)
objSB.Append(vbCrLf & Me.StackTrace)

Return objSB.ToString()

End Function

End Class


Here is the output after catching the exception in the calling application:

System.ApplicationException: The zonal analysis properties could not be
mapped f
rom the database

Server stack trace:
at NZDF.Air.AircraftReview.IZoneAnalysisRetrieve.Retrieve(Int32 ID,
clsZonalA
nalysis& Entity)
at
System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(M
ethodBase mb, Object[] args, Object server, Int32 methodPtr, Boolean
fExecuteInC
ontext, Object[]& outArgs)
at
System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMes
sage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
req
Msg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgDa
ta, Int32 type)
at
NZDF.Air.AircraftReview.clsZonalAnalysisRetrieveController.Retrieve(Int32
ID, clsZonalAnalysis& Entity)
at
NZDF.Air.AircraftReview.clsCoveredTasksTester.TestCoveredTaskNTestRefreshW
ithTasks() in
D:\DotNetProjects\ARSSln\ARSNet\testHarness\CoveredTasksTester.vb:
line 264
at ARSNetTester2.Class1.Main() in
D:\DotNetProjects\ARSSln\ARSNetTester2\Clas
s1.vb:line 15


Note that the caught exception is the ApplicationException class that my
exception is inherited from, the message matches the custom exception but the
inner exception object is not present.

 

[Peter Huang]

Hi,

I think this is an known issue, you may take a look at the link below.

All is not lost, however. The CLR has a large list of HRESULTs that it
knows how to transform into specific exception types. Because I derived
CustomAppException from ApplicationException, I inherited the base HRESULT
value. This is why my type became an ApplicationException after passing
through unmanaged code. Had I not derived my exception type from
ApplicationException or another exception type for which the CLR has a
built-in HRESULT, the returned type would have been a COMException (when
the CLR gets an unrecognizable HRESULT across the interop boundary, it
creates a COMException).

Throwing Custom Exception Types from a Managed COM+ Server Application
http://msdn.microsoft.com/msdnmag/issues/04/03/ExceptionsinCOM/default.aspx

Also here are some links about the issue, you may take a look.

http://groups.google.com/groups?hl=zh-CN&lr=&ie=UTF-8&c2coff=1&threadm=1bjoZ
1jEEHA.1996%40cpmsftngxa06.phx.gbl&rnum=1&prev=/groups%3Fq%3D%2522v-yiy%2522
%2Bexception%2B%2522COM%252B%2522%26hl%3Dzh-CN%26lr%3D%26ie%3DUTF-8%26c2coff
%3D1

http://groups.google.com/groups?hl=zh-CN&lr=&ie=UTF-8&c2coff=1&threadm=#VS
Xf5dMEHA.3944%40tk2msftngp13.phx.gbl&rnum=3&prev=/groups%3Fhl%3Dzh-CN%26lr%3
D%26ie%3DUTF-8%26c2coff%3D1%26q%3D%2522Custom%2BExceptions%2Bin%2BCOM%252B%2
522

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thank you Peter

From the article, I see that the code only seems to work when the wrapper
class is called from the client (managed). I wish to raise the exception
from within the server component itself.

I have tried calling the wrapper to raise and exception yet the client still
only gets an ApplicationException if I call this wrapper class from within my
Server component

What steps do I need to take to achieve this functionality

 

[Peter Huang]

Hi

Do you mean throw the customized exception from Managed component and
handle the customized exception in managed client as Application Exception?
I think this is by design.
You may try to look into the figure 3 in the link below.
http://msdn.microsoft.com/msdnmag/issues/04/03/ExceptionsinCOM/fig03.gif

The picture is in the link below.
http://msdn.microsoft.com/msdnmag/issues/04/03/ExceptionsinCOM/default.aspx

Because after across the COM interop layer, the customized exception
information has lost.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks, most helpful

I will handle the inherited ApplicationException from my calling application
instead