Topic: Block Reference ?

[Micaletti]

Agreed. Good post.

When catching exceptions in a way you are saying you expected this might happen, and you understand why it happened, and you know how to deal with it.

Not always. Sometimes you are saying, I didn't expect anything to happen so what the hell happened? Especially when its in an example for a person using an unfamiliar API. I agree you should probably rethrow the exception if you're not going to actually handle it.

[Jeff H]

Sorry if it implied that a using statement is better than a Try/Finally, but if used for guaranteeing that dispose is called on a object I prefer Using.
 
As for which one is better I can't really compare a Try/Catch/Finally because if Catch functionality is needed then need to use a Try/Catch/Block, and if any other code needs to execute in Finally block other than Dispose then a Try/Finally would be required.
 
When using a Try/Finally to accomplish the equivalent functionality as a using block then I can give no reason why one would be better than the other, other than preference.
 
Could also do
 
OnError GoTo Handler
....
...
GoTo Final
 
Handler:
Goto Final
 
Final:
Dispose()
 
 
 
 

[exmachina]

There is no difference between the "using" Statement and a "try/finally" block, internally is the same (MSIL) code. If anyone has any doubt about this and about the performance,  take a look at this:

C# code

Code - C#: [Select]

1. public void func1(){
2.     using (MemoryStream stream = new MemoryStream()){
3.     }
4. }
5.  

MSIL Code



C# code

Code - C#: [Select]

1. public void func2(){
2.     MemoryStream stream = new MemoryStream();
3.  
4.     try{
5.     }finally
6.     {
7.         stream.Dispose();
8.     }
9. }
10.  

MSIL Code

[MexicanCustard]

Micaletti, you were telling someone not to use the Using statement which could be confusing since most of the examples they will be looking at will have the Using statement in them.  Your right putting a Using statement inside a Try/Catch/Finally block is redundant but during development I'll put a Using statement inside a Try/Catch block until I'm finished debugging. Then all I have to do is remove the Try/Catch and leave the Using.

The only methods you call in your example are part of the AutoCAD API and if you've ever crashed inside of one of their method calls you know that AutoCAD blows up and never returns to your try/catch.  Thats specific to the example you posted, I'm not saying that using the AutoCAD API will always blow up and not return to your try/catch just the example you posted.

[jcoon]

Thanks for the descriptions and advice it really helps

Thank you,
John

[Micaletti]

Micaletti, you were telling someone not to use the Using statement which could be confusing since most of the examples they will be looking at will have the Using statement in them.  Your right putting a Using statement inside a Try/Catch/Finally block is redundant but during development I'll put a Using statement inside a Try/Catch block until I'm finished debugging. Then all I have to do is remove the Try/Catch and leave the Using.

The only methods you call in your example are part of the AutoCAD API and if you've ever crashed inside of one of their method calls you know that AutoCAD blows up and never returns to your try/catch.  Thats specific to the example you posted, I'm not saying that using the AutoCAD API will always blow up and not return to your try/catch just the example you posted.

MC I still have no idea what you are talking about. Your OP wasn't clear and neither is this one. Specific to what exactly? AutoCAD exceptions inherit System.Exception. It catches everything unless you blow up AutoCAD, which has nothing to do with Try/Finally, Using, or my example. That's true for everything. In fact using doesn't catch anything, so what is your point sir?

The reason I told him that I would avoid Using is because hes going to be catching lots of exceptions while learning the API. You just said that you yourself do. Catch provides feedback. Using doesn't.

[owenwengerd]

Catch provides feedback. Using doesn't.

You are mistaken. Catching exceptions indiscriminately is a very, very bad idea (in general, but especially when learning an API) precisely because it hides errors and propagates invalid or unexpected program state to a later point in the code where the cause is less obvious. This doesn't have anything to do per se with Using, which seems to me clearly superior to Try/Catch/Finally for encapsulating IDisposable object lifetime.

[Micaletti]

Catch provides feedback. Using doesn't.

You are mistaken. Catching exceptions indiscriminately is a very, very bad idea (in general, but especially when learning an API) precisely because it hides errors and propagates invalid or unexpected program state to a later point in the code where the cause is less obvious. This doesn't have anything to do per se with Using, which seems to me clearly superior to Try/Catch/Finally for encapsulating IDisposable object lifetime.

Jeff has already pointed that out and I have already agreed. You can catch the exception, provide some feedback, then throw it again can't you? That would be exactly the same as using but with some feedback wouldn't it?

I agree you should probably rethrow the exception if you're not going to actually handle it.

I work specifically with the ACA/MEP API which has almost zero documentation and is riddled with eNotImplementedYet and the like. I can't begin to tell you how useful that catch feedback has been. With that said I have nothing against Using and don't intend to debate any further about it.

[owenwengerd]

You can catch the exception, provide some feedback, then throw it again can't you? That would be exactly the same as using but with some feedback wouldn't it?

Yes, you can do that, but it would be a mistake (and most certainly not the same thing). During development your debugger will catch exceptions at the earliest possible point where you have the best chance to find and fix the cause. Catching exceptions at runtime should be done for a different purpose, namely to gracefully recover (or yes, in some cases rethrow when a graceful recovery is not possible). I can think of very few scenarios where it would be wise to intentionally catch eNotImplementedYet exceptions at runtime; those should be found and addressed while the program is under development. At runtime they should remain unhandled so the program code immediately ceases execution.

[Micaletti]

Thanks Owen, I needed to hear that. I'm curious now, what is the proper way to report unforeseen exceptions that end users may experience?

I would also like to say that while its *possible* you could corrupt a database, explode a monitor, or launch a missile by msgboxing a caught exception *gasp*, it's highly unlikely in this context (debugging) and is a common "mistake" found everywhere, including autodesk university examples, these forums, google etc. I've never seen AutoCAD handle any exceptions on it's own, and have not had any problems with it in many thousands of lines of code.

Immediately ceasing execution as you suggested could also directly or indirectly cause a database to be corrupted or a missile to be unintentionally launched. The only bullet proof method is to be omniscient and handle everything.

Using your cellphone could give you brain cancer.

[owenwengerd]

I'm curious now, what is the proper way to report unforeseen exceptions that end users may experience?

I think the .NET framework and AutoCAD do a pretty good job of reporting exceptions. The .NET framework insulates managed code from the underlying native AutoCAD code in such a way that many exceptions can be reported and the managed code halted, while still rolling the native system back into a safe and stable state so that the user can go on working in AutoCAD. Furthermore, AutoCAD does a good job of recovering when possible, or otherwise shutting down immediately before further damage is done. So to answer your question, I think exception reporting should be left to AutoCAD unless you have a specific reason not to.

The fallacy that many novice programmers make is believing it important to hide exceptions from end users. Exceptions are a useful resource, and it's less important how they are reported, just that they are reported. It's always the quiet ones that cause the most grief.

[owenwengerd]

I should add for completeness that there are edge cases where every exception should be caught indiscriminately and reported manually. A notable case with AutoCAD plugins is during module initialization (i.e. IExtensionApplication::Initialize), where AutoCAD quietly ignores exceptions. That is a design flaw in AutoCAD's loader that must be "fixed" in user code, unfortunately.