views:

73

answers:

1

I'm of the understanding that an unhandled exception in any appdomain will bring down that appdomain. This is not unlike an unhandled exception in any standard forms- or console-based application.

If that is so, how do you indicate a failed operation when you're crossing appdomain boundaries? I'm currently logging it so that I know it happens, but the operation is one of several taking place within a method and I don't think anything short of an exception is going to interrupt that method.

To put something more concrete to this, I'm setting a string property on an object (proxy) created in another appdomain. This operation takes place in the other appdomain, but if it fails for some reason I don't want to continue with the other operations. They all take place in a single method because I need it all to happen as a single atomic operation. If any of the operations fail, the atomic operation as a whole needs to fail.

I thought about something like a "last operation status" indicator that I could check after each one, but that seems kludge. Is there a better way?

+1  A: 

If the code in the second AppDomain is executing because of a call from code in the first, then there shouldn't be a problem throwing an exception. As far as I'm aware, the runtime should pass the exception back to the calling AppDomain instead of treating it as an unhandled exception. I believe this is part of the reason for the recommendation that all exceptions be serializable.

Rory
If that is true, then I really need to look at what I'm doing. I'm having an appdomain be unloaded without my say-so so when I try to unload it myself later, I'm getting the message "The target application domain has been unloaded." * digs deeper *
oakskc
Sounds painful... How exactly are you calling from the one domain into the other? I'm sure exceptions should work if its a simple method call on a proxy object.
Rory
Yep, a proxy created by Activator.CreateInstance. That's why I think that what you said means that I need to be looking elsewhere. It seemed to make sense at the time, but that's why you go on these journeys, to find out what you don't know.
oakskc
So wait, was I right? I think I just found an article saying that I'm hopelessly wrong... now I'm really confused :-/
Rory
Can you post a link to the article? With some more digging, I'm finding the situation occurring by creating an instance of an object in the other appdomain and then disposing of that instance. No exceptions (that I'm catching), but the appdomain goes away silently. I'm causing this, I know it, but I'm missing something and I just have to find it.In my original problem, I was creating an instance and then raising an exception from within that instance. If this has to do with how I'm releasing that instance, then they have the same cause and I was chasing a red herring.
oakskc
http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx Can't remember what it was I saw, but it made me think there might be more to this problem. Have a read through it and let me know what you think. It's late and I think I'm losing my mind, so I'm gonna call it a night. Good luck
Rory
Thanks for the information! I'll read up on appdomains and exceptions.In the meantime, I have tracked down the problem. I have a class that manages my appdomains for me. I forgot that I had created that class as a singleton. When I was telling what I thought was one instance of the manager class to kills its domains, it was killing ALL domains it had created. Then when I later went to cleanup an instance created in one of those domains, it wasn't there. Like I said, it was all my doing! My logging made it look as if the exception caused it, but it (I) was wrong. Thanks!
oakskc