OFF TOPIC:
Its also interesting because a try {} catch {} is optimized out with
an empty catch (finally with empty finally) ... this changes the JIT
compiled code. These changes can have visible side effects ...
as such code like
try {
}
catch(Exception Ex) {
Debug.Write(Ex);
}
can have slightly differing behaviors if #DEBUG is enabled.
Personally this is one optimization I could do without :)
Cheers,
Greg
On 8/7/07, Marc Brooks <[EMAIL PROTECTED]> wrote:
> > Usually when people talk about compiler optimizations they mean the JIT.
> > CSC does precious little optimization.
>
> Isn't that the truth (of course that feeds my need for speed at compile time)
>
> > (http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/default.aspx
> > ?side=true#a)
>
> VERY interesting reminder tucked in that document, thanks!
>
> "A Try-Finally with no code in the Try is left completely alone. This
> is because the semantics of code executing in a Finally block and
> outside of it are different. Asynchronous ThreadAbort exceptions
> (those thrown by another thread) may interrupt the execution of all
> code, except for code found in Finally blocks."
>
> --
> "It's not the quality of journalism that is sinking e-media companies, it
> the quality." Thom Calandra - CBS Marketwatch
>
> Marc C. Brooks
> http://musingmarc.blogspot.com
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>
--
Studying for the Turing test
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
