Try..Catch in VB different to C# - Why?

[Daniel Moth]

Hi

In short the question is:
Why does VB generate 2 extra lines/calls for the catch compared to C#?

i) straight after catch it puts
call void
MS.VB.CompilerServices.ProjectData::SetProjectError(System.Exception)

ii) and the penultimate line before exiting catch is
call void
MS.VB.CompilerServices.ProjectData::ClearProjectError()

The detail:
Given a function such as:

Public Sub SomeMethod()
Try
System.Console.WriteLine("Hi")
Catch
System.Console.WriteLine("Whatever")
End Try
End Sub

or in C# if you like

public void SomeMethod(){
try{
System.Console.WriteLine("Hi");
}
catch{
System.Console.WriteLine("Whatever");
}
}

The generated IL for C# is:

.method public hidebysig instance void SomeMethod() cil managed
{
// Code size 26 (0x1a)
.maxstack 1
.try
{
IL_0000: ldstr "Hi"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: leave.s IL_0019
} // end .try
catch [mscorlib]System.Object
{
IL_000c: pop
IL_000d: ldstr "Whatever"
IL_0012: call void [mscorlib]System.Console::WriteLine(string)
IL_0017: leave.s IL_0019
} // end handler
IL_0019: ret
} // end of method TryCSharpCatch::SomeMethod

whereas the generated IL for VB is:

.method public instance void SomeMethod() cil managed
{
// Code size 35 (0x23)
.maxstack 1
.try
{
IL_0000: ldstr "Hi"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: leave.s IL_0022
} // end .try
catch [mscorlib]System.Exception
{
IL_000c: call void
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.ProjectData::S
etProjectError(class [mscorlib]System.Exception)
IL_0011: ldstr "Whatever"
IL_0016: call void [mscorlib]System.Console::WriteLine(string)
IL_001b: call void
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.ProjectData::C
learProjectError()
IL_0020: leave.s IL_0022
} // end handler
IL_0022: ret
} // end of method TryVbCatch::SomeMethod

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

If I had to guess, I would think that it has something to do with
maintaining compatability with the "on error" error handling keywords. Of
course, I have my personal opinions about this, but I'll refrain =)

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- nicholas...@exisconsulting.com

"Daniel Moth" <dmo...@hotmail.com> wrote in message
news:#NAlpFXvCHA.2028@TK2MSFTNGP11...

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

Well, you can always decompile your code with ILDASM, edit it, and then
recompile with ILASM. =)

--
- Nicholas Paldino [.NET/C# MVP]
- nicholas...@exisconsulting.com

"Daniel Moth" <dmo...@hotmail.com> wrote in message

news:ux6$AxXvCHA.1628@TK2MSFTNGP10...
> Yeah that would be my guess...
>
> What irritates me is the fact that I have painfully gone through and
> replaced all "on error" handling with try..catch in 10s of thousands of
> lines of VB code only to find that it still thinks I need it at the IL
> level.
>
> They appear there even if the project has no references to anything but
> System. There must be a (slight) performance impact because of this
> surely... Anyway to remove them... anybody?
>
> Cheers
> Daniel
>
> PS This came to my attention while investigating a related bug (because
> of these lines) in the Compact Framework.
>
>
>
> "Nicholas Paldino [.NET/C# MVP]" <nicholas...@exisconsulting.com>
wrote
> in message news:Oz#pieXvCHA.2532@TK2MSFTNGP10...

[Daniel Moth]

Yeah that would be my guess...

What irritates me is the fact that I have painfully gone through and
replaced all "on error" handling with try..catch in 10s of thousands of
lines of VB code only to find that it still thinks I need it at the IL
level.

They appear there even if the project has no references to anything but
System. There must be a (slight) performance impact because of this
surely... Anyway to remove them... anybody?

Cheers
Daniel

PS This came to my attention while investigating a related bug (because
of these lines) in the Compact Framework.

"Nicholas Paldino [.NET/C# MVP]" <nicholas...@exisconsulting.com> wrote
in message news:Oz#pieXvCHA.2532@TK2MSFTNGP10...

[Daniel Moth]

If I understand your reply I think you are missing the point.

My post refers to the differences at the IL level...

Please read again or correct me if I misunderstood...

Cheers
Daniel

"Scot Rose [MSFT]" <sc...@online.microsoft.com> wrote in message
news:jFvjKeXvCHA.896@cpmsftngxa09...
> Because that is VB's Syntax... Not things like the Select Case....End
Select, Sub....End Sub, Function.... End Function, Type....End Type. Its
the way VB has been
> since well..... Quick Basic<G> In the interest of consisitancy it would
have been confusing when they Added try catch to not have made it Try....
End Try...
>
> Want to know more? Check out the MSDN Library at http://msdn.microsoft.com
or the Microsoft Knowledge Base at http://support.microsoft.com
>
> Scot Rose, MCSD
> Microsoft Visual Basic Developer Support
> Email : sc...@online.microsoft.com <Remove word online. from address>
>
> This posting is provided "AS IS", with no warranties, and confers no
rights.
>
>
>
>
>

[Mark Pearce]

Hi Daniel,

I don't know what the two extra calls are doing. Maybe it's something to do
with the fact that the catch for the C# CIL is "System.Object" whereas the
catch for the VB CIL is "System.Exception". The argument for the extra call
is "System.Exception".

Notice that if there is a performance hit (don't you just hate those
microsecond delays), it only occurs when an exception is triggered. On the
normal code execution path, exceptions won't usually be triggered, so the
performance hit won't be occurred. In addition, the overhead when an
exception is triggered is likely to dwarf the delay for the extra call.

Regards,

Mark

"Daniel Moth" <dmo...@hotmail.com> wrote in message

news:ux6$AxXvCHA.1628@TK2MSFTNGP10...

[Daniel Moth]

Well, I could... but then again I am not in the army nor in prison... ;-)

Hoping someone from the VB compiler team will offer their insights...

Cheers
Daniel

"Nicholas Paldino [.NET/C# MVP]" <nicholas...@exisconsulting.com> wrote

in message news:OjgsB3XvCHA.1620@TK2MSFTNGP11...

[Daniel Moth]

Hi thanks for reply...

You are right about the performance but I have to justify somehow why I
don't like these 'extra' lines :)

The truth is that if these lines were not inserted my app would not 'die'
under circumstances on the .NET Compact Framework.. (relevant bug posted in
cf newsgroup)

I am now intrigued with the catch_Object vs catch_Exception (well spotted by
the way)... Any idea what's going on there?

Cheers
Daniel

"Mark Pearce" <ev...@bay.com> wrote in message
news:Oc8BanYvCHA.640@TK2MSFTNGP12...

[Mark Pearce]

Hi Daniel,

Good question - I don't know the answer, but I'm going to experiment tonight
with different catch clauses and also take a look at
MS.VB.CompilerServices.ProjectData.

Regards,

Mark

"Daniel Moth" <dmo...@hotmail.com> wrote in message

news:eiCKwsYvCHA.2124@TK2MSFTNGP11...

[Daniel Billingsley]

And things like point out why I have chosen C# going forward and not VB.Net.
VB fans can argue all they want that they're functionally nearly identical,
but the design purpose and heritage between the two is radically different,
and could easily diverge again in the future.

"Nicholas Paldino [.NET/C# MVP]" <nicholas...@exisconsulting.com> wrote
in message news:Oz#pieXvCHA.2532@TK2MSFTNGP10...

[VBDotNet Team [MS]]

The extra two calls are there to support the "On Error" language feature
that was retained to make it easier to upgrade from VB6 to VB.NET. Like Mark
Pearce pointed out, they only cost you time (and very little) if an
exception actually happens. The time for the two calls is minor compared to
the overhead of propagating exceptions.

Niklas
VB Compiler Team

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Daniel Moth" <dmo...@hotmail.com> wrote in message

news:O7LC2kYvCHA.2592@TK2MSFTNGP10...

[Chad Myers]

There should be a compiler flag like the /unsafe in C# for
VB.NET's "On Error" syntax.

In fact, /unsafe would be fitting :)

Or, perhaps /unmaintainable ;)

-c

"VBDotNet Team [MS]" <vbdo...@microsoft.com> wrote in message
news:uNwHj1ZvCHA.2424@TK2MSFTNGP10...

[Daniel Moth]

Thanks for reply

There are cases where (due to third party dlls) we have to have try..catch
statements where the catch part is empty (well not so empty it seems now).
But leaving aside the performance issue (or non-issue), why aren't these
calls inserted ONLY if the "On Error" feature is used in the project(s)?

I think that there should be some option for this... It could even be that
the calls are not inserted if the project does not reference the VB
namespace...

Cheers
Daniel

"VBDotNet Team [MS]" <vbdo...@microsoft.com> wrote in message
news:uNwHj1ZvCHA.2424@TK2MSFTNGP10...
>

[Daniel Billingsley]

You and Jerimiah need to create a standup act. LOL!

"Chad Myers" <cmy...@N0.SP.4M.austin.rr.com> wrote in message
news:v%EV9.61562$Pb.21...@twister.austin.rr.com...

[Chad Myers]

Good idea!

One other comment, /umaintainble would be redundant
when compiling VB.NET code ** ;)

-c

** This is not to diminish the hard work of the VB.NET
compiler team, but just a general stereotypical
crack on VB developers in general.

"Daniel Billingsley" <dbilli...@NO.durcon.SPAAMM.com> wrote in
message news:#iu2etavCHA.2668@TK2MSFTNGP12...

[Mark Pearce]

Hi Daniel,

Try choosing both...it's hardly quantum physics. Every language in which you
do significant coding gives you different insights into design and coding,
and can make you a better developer if you have the right attitude.

In my (admittedly long) career, I've had to code or at least understand Z80
assembler, 8088 assembler, Fortran, Nixdorf Business Basic, BBC Basic (I
loved my BBC Model B), Atari Basic (I hated my Atari 800), RPG3, RPG400,
PL/1, FoxPro, Visual FoxPro, T-SQL, VB.Classic, VB.NET, C#, Microsoft
marketing...

Admittedly, the last one tested my philosophy the most.

Regards,

Mark

"Daniel Billingsley" <dbilli...@NO.durcon.SPAAMM.com> wrote in message

news:uz7H2tZvCHA.2544@TK2MSFTNGP11...