Getting CurrentException without catch.

[Paulo Zemek]

Is there a way to discover which is the actual exception, without using the catch block? For example: Dispose() will be called if there is an exception or not. I want to know if this Dispose is happening naturally, at the end of the block or by an exception that forced the end of the block. My idea is simple test something like: Exception.GetCurrentException() != null But I don't know if there is somewhere to look for this.

[Lost User]

Paulo Zemek wrote:

Is there a way to discover which is the actual exception, without using the catch block?

This is the second question on this subject that makes no sense. The try/catch construct is there for a reason, so make use of it and stop your programs from causing havoc.

[Luc Pattyn]

Paulo Zemek wrote:

Dispose() will be called if there is an exception or not.

if you have a using statement, yes, Dispose() will be called no matter what. The functionality of Dispose() is to dispose of managed and/or unmanaged resources, independent of circumstances; so you are not even entitled to know if and which exception has occurred. :)

Luc Pattyn [Forum Guidelines] [My Articles]

---

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

---

[Lost User]

Don't use 'using' block, try this instead:

bool isOK = true;

try {
..........
..........
}
catch {
isOK = false;
}
finally {
if (!isOK) {
} else {
}
}

[Paulo Zemek]

I know I can do this with try/catch/finally. But I really want to know if there is any way to discover if the method I am is actually called by an exception (is inside a catch/finally) or not. The purpose is to make the method simpler to use, as the caller of the method will not be required to pass the exception (or the boolean) as parameter. A very ugly example: using(var someTransaction = new MyTransaction()) { ... code here ... someTransaction.Commit(); } And then, in Dispose, I will check: If the transaction was committed/rollbacked, do nothing. If the transaction was not committed or rollbacked, but there is no exception, I will throw an exception telling that Commit or Rollback is required. If there is already an exception, I will rollback and keep the original exception. - Note: I know how to use try/catch/finally. But I really want to make the use of the code simpler for the others. using keyword looks nicer than try, catch and finally.

modified on Monday, November 23, 2009 12:38 PM

[The Man from U N C L E]

One possible solution is to have a global variable which all try/catch code can log their exception to. (Probably best to make that a List and process stuff on or off that exception stack.) Any code can then test the global exception variable to see if there is an exception outstanding. Once you have acted appropriately to that exception then clear it off the stack.

If you have knowledge, let others light their candles at it. Margaret Fuller (1810 - 1850) www.JacksonSoft.co.uk

[Paulo Zemek]

But this brings the original problem again: The developer will need to "add/remove" exceptions manually. My question is simple: .Net has something like that built in (in any class) or not? I originally thought that I could find catch using StackTrace, but it has no information about catchs. Is there any way to discover this, even if this is an expensive operation? After all, this will be used only in Debug code. -> To be honest, I really think that .Net must register exceptions automatically in a "FILO/LIFO" queue and so, when one exception is thrown inside a catch it could automatically fill the "inner exception" property without manual coding. Of course, such list must be ThreadStatic, as one thread can be executing normal code, while the other is executing a catch inside a catch.

[Lost User]

In ASP.NET, there is something like Server.GetLastError();

[dojohansen]

Short answer: No. There are sometimes ways to get an otherwise unhandled exception without a try-catch. In asp.net apps for example you can handle Application_OnError. But it's not a substitute for exception handling elsewhere in the code, only a last-resort chance to at least do things like log errors. You can use either delegates or polymorphism if you want to standardize exception handling in certain situations. Something like this would be possible:

public static class DbHelper
{
public static RunInTransaction(SqlConnection cnx, Action method)
{
cnx.Open();
SqlTransaction tx = cnx.BeginTransaction();
try
{
method();
tx.Commit();
}
catch (Exception ex)
{
tx.Rollback();
throw new ApplicationException("Error during database transaction.", ex);
}
finally
{
cnx.Close();
}
}
}

Here I used the predefined Action delegate, which is void and takes no parameters, but you could of course use any delegate you'd like. Or you could use polymorphism: It could be an abstract method that derived classes must implement (obviously the class then can no longer be static!), or the method could accept an object implementing some interface instead of a delegate. There are some cool possibilities with IDisposable but it is really intended specifically for early release of non-managed resources. It's not meant to be a general try-finally replacement, and certainly not a try-catch-finally replacement.

modified on Monday, November 23, 2009 2:39 PM

[Daniel Grunwald]

For a solution usable inside Dispose(), please see http://ayende.com/Blog/archive/2007/06/20/Did-you-know-Find-out-if-an-exception-was-thrown.aspx[^] and http://blogs.microsoft.co.il/blogs/sasha/archive/2007/07/01/Using-Marshal.GetExceptionCode_28002900_.aspx[^]. However, I'd just use a method taking a callback delegate:

DoStuff(delegate {
...
});

then you can use whatever try-catch construct you want inside DoStuff.

[Paulo Zemek]

Thanks a lot. This solves my problem!