Comments by Tomáš Vepřek (Top 5 by date)

Well take for example a WCF service and ServiceHost object. This object doesnt implement dispose but you have to close it or call abort. The use of catch block in finally here is that abort and close both can raise and exception but you want to call them always. Its just an example, i just want to say that there always can be code where you may have to catch exception in dispose or finally block.

I agree that in scenario where you want whole code in try catch block like this: try { }catch{} finally {} it wont be shorter but if you need this try{} finally { try{ } catch{} } or just plain try{ }finally and let some other code in callstack handle exception i think it may have some use.

As i posted earlier you can put try catch block from finally into dispose method of Finalizer and make it much more reusable.

Well think of what you can do with this, you can for example make some big try catch block in dispose method for example :

try
{
if (Action != null)
Action.DynamicInvoke();
}
catch(NullreferenceException)
{
}
catch(FileNotFoundException)
{
}

I think you'll get the idea. And using this you will shorten the final code and have some business logic inside Finalizer.

Well this is exactly what i wanted to hear :)
I dont want to catch the exception, i want the caller to get it and do whatever he likes with it. Caller will know that something went wrong what makes you think he doesnt ? Exception still occures and its up to him to catch it but maybe not on the level where he calls this method.

The idea was to make same functionality with different syntax.