
Signature
omnibus ex nihilo ducendis sufficit unum
Spaces inserted to prevent google email destruction:
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog
Thanks for your reply.
As I said in my original post, this a simplification of my problem, but my
problem is much more complex, so I cannot do as you propose. The fact is,
that all my logic handling the transaction is wrapped in a class, that is
disposed using the using statement.
But in my transactionhandling's Dispose implementation I want to determine
if an exception was thrown
using( TransactionHandling t = new TransactionHandling())
{
}
> Peter wrote:
>
[quoted text clipped - 56 lines]
>
> Oliver Sturm
"Peter Huang" [MSFT] - 12 Aug 2005 04:01 GMT
Hi
I think the finally is target at handle the code finished job, somewhat
like the deconstructor.
Its code should be not related with whether there is an exception.
I think you may try to change your design to use the try...catch...finally
block.
Try
{
//the code which may have exception
}
//handle the proper exception
catch(exception A)
{
}
catch(exception B)
{
}
finally
{
//clean up job
e.g. the try block may create a temp file, then the file need to be deleted
whenever the exception occur.
}
If you do want to do that, I think a possible approach is to use bool flag,
to set it to true at the every end of the try block, so in the finally
block you can detect the bool flag to know if the try is exit at the end.
BTW:
So far Whidbey issue is not officially supported, so the behavior may vary
after the finally release.
For Whidbey issue, you may try to report in the vs2005 forum.
http://lab.msdn.microsoft.com/vs2005/community/
Best regards,
Peter Huang
Microsoft Online Partner Support

Signature
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
Oliver Sturm - 12 Aug 2005 09:53 GMT
Peter wrote:
> As I said in my original post, this a simplification of my problem, but my
> problem is much more complex, so I cannot do as you propose. The fact is,
[quoted text clipped - 6 lines]
> {
> }
I understand, but I still think you should handle things differently :-)
For example, you could rethrow the exception to be caught outside your
transaction handling encapsulation. Or, if you absolutely want to break
out of the standard exception handling system, you could store away the
exception information in a catch block inside the class and evaluate
that information from the outside later on.
I thought I had at some point heard or read something about a way to
detect whether "there is currently an exception". But I was unable to
find whatever it was I had in mind there. The other thing is: Such a
mechanism could obviously only work if the exception was still "active"
at that point, in contrast to having been swallowed by a catch block
earlier on. So if the exception is really active at this point in your
code, what would keep you from simply catching it with a catch block?
What you are asking is, apparently, "how do I find out if an exception
was thrown before I got to the point where I'm now". The answer to that
will usually be yes, of course, because exceptions are thrown and caught
many times during the run of a .NET application (even though we all know
they shouldn't be used for flow control in the main execution path). Now
you are going to modify the question to say "I'm not interested in all
exceptions that might have been thrown before I got to the current
point, only in those that might have been thrown during the use of the
TransactionHandling class." So if that is your actual question, let me
ask again: Why don't you put an external try/catch around the use of the
TransactionHandling class and find out?
Oliver Sturm

Signature
omnibus ex nihilo ducendis sufficit unum
Spaces inserted to prevent google email destruction:
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog