Re: MAJOR Try... Catch... Finally BUG! - Repost for Formatting

[David Williams]

Sorry for the repost, but the first was almost unreadable....

I have found what seems to be a MAJOR bug with VB.NET's structure error handling when working with XML types. I have confirmed that I can cause this behavior on different systems. Has anyone else run across this?

Try the following code in a new Console Application:
Option Strict On
Imports SystemImports System.Xml
Module Module1
Sub Main()
Dim testXML As XmlDocument = New XmlDocument()Dim steps As XmlNodeListDim tag As XmlNodeDim retVal As XmlNode
Console.WriteLine("Starting Main")Try
testXML.LoadXml("<root><item><test cond='false'/></item></root>")steps = testXML.SelectNodes("*/item")For Each tag In steps retVal = Test(tag, Nothing)Next
Catch ex As Exception Console.WriteLine("Main caught: " & ex.Message)
Finally Console.WriteLine("Press enter to exit") Console.ReadLine()
End Try
End Sub
Private Function Test(ByVal tag As XmlNode, ByVal dummy As XmlNode) As XmlNode
Dim selectedTag As XmlNode = NothingDim selected As XmlElementDim att As String
Console.WriteLine("In Test")
Try
If tag Is Nothing Then Exit TryEnd If
For Each selectedTag In tag
selected = CType(selectedTag, XmlElement)If dummy Is Nothing Then att = selected.GetAttribute("cond") If att = "false" Then Console.WriteLine("Found attribute cond = false") Exit Try End IfElse If selectedTag.Name = dummy.Name Then Exit Try End IfEnd If
Next
selectedTag = NothingConsole.WriteLine("SelectedTag is nothing")
Catch ex As Exception Console.WriteLine("Test caught: " & ex.Message)
Finally Console.WriteLine("Test Done")
End Try
Return selectedTag
End Function
End Module
"David Williams" <d.w.i.l.l.i.a.m.s.@strohlsystems.com> wrote in message news:3cdc7184$1@10.1.10.29...
> I have found what seems to be a MAJOR bug with VB.NET's structure error
> handling when working with XML types. I have confirmed that I can cause
> this behavior on different systems. Has anyone else run across this?
>
> Try the following code in a new Console Application:
> Option Strict On
> Imports SystemImports System.Xml
> Module Module1
> Sub Main()
> Dim testXML As XmlDocument = New XmlDocument()Dim steps As XmlNodeListDim
> tag As XmlNodeDim retVal As XmlNode
> Console.WriteLine("Starting Main")Try
> testXML.LoadXml("<root><item><test cond='false'/></item></root>")steps =
> testXML.SelectNodes("*/item")For Each tag In steps retVal = Test(tag,
> Nothing)Next
> Catch ex As Exception Console.WriteLine("Main caught: " & ex.Message)
> Finally Console.WriteLine("Press enter to exit") Console.ReadLine()
> End Try
> End Sub
> Private Function Test(ByVal tag As XmlNode, ByVal dummy As XmlNode) As
> XmlNode
> Dim selectedTag As XmlNode = NothingDim selected As XmlElementDim att As
> String
> Console.WriteLine("In Test")
> Try
> If tag Is Nothing Then Exit TryEnd If
> For Each selectedTag In tag
> selected = CType(selectedTag, XmlElement)If dummy Is Nothing Then att =
> selected.GetAttribute("cond") If att = "false" Then
> Console.WriteLine("Found attribute cond = false") Exit Try End
> IfElse If selectedTag.Name = dummy.Name Then Exit Try End IfEnd
> If
> Next
> selectedTag = NothingConsole.WriteLine("SelectedTag is nothing")
> Catch ex As Exception Console.WriteLine("Test caught: " & ex.Message)
> Finally Console.WriteLine("Test Done")
> End Try
> Return selectedTag
> End Function
> End Module
>
>
>

[David Bayley]

David Williams wrote:
> Sorry for the repost, but the first was almost unreadable....

It would also help if you explained what the problem was... but I
managed to reduce the code further to:

Option Strict On
Imports System
Imports System.Collections
Module Module1
Sub Main()
Console.WriteLine("Start")
Dim items As New ArrayList
items.Add(New Object())
Try
Dim item As Object
For Each item In items
Console.WriteLine("Exit Try")
Exit Try
Next item
Console.WriteLine("D'Oh")
Finally
Console.WriteLine("Finish")
End Try
End Sub
End Module

Which outputs:
Start
Exit Try
D'Oh
Finish

The "D'Oh" output does seem like a bad bug, unless I'm missing something
obvious. The ForEach loop over an IEnumerable collection is required
(e.g. foreach'ing over an Int32 array works fine, sans D'Oh).

<shrug/>. One solution is to ban the Exit keyword from your code...
it's as bad as Goto IMO.

--
David

[David Williams]

Ok, let me be more clear. I have reduced the code and explained a little:

I have found what seems to be a MAJOR bug with VB.NET's structured error
handling when working with
XML types.

An "Exit Try" statement is designed to do exactly that, exit the Try block
via the Finally area without
running any addtional code from within the Try block. In this case, the
"Exit Try" is performing an
"Exit For" instead of an "Exit Try". I tried the same structures without
using the XML types and it
works as expected... the next statement executed after the "Exit Try" is the
first statement of the
"Finally" block.

I have confirmed that I can cause this behavior on different systems. Has
anyone else run across this?

If the code that follows worked as expected, I should see this output:

Starting Main
In the If Block
Test Done
Press enter to exit

however what I see is this:

Starting Main
In the If Block
Exited Inner For Loop
Test Done
Press enter to exit

Here is the test code that I used to duplicate the problem. In a new
Console Application:

Option Strict On
Imports System
Imports System.Xml

Module Module1

Sub Main()

Sub Main()
Dim testXML As XmlDocument = New XmlDocument()
Dim steps As XmlNodeList
Dim tag As XmlNode
Dim retVal As XmlNode
Dim selectedTag As XmlNode = Nothing

Console.WriteLine("Starting Main")
Try
testXML.LoadXml("<root><item><test cond='false'/></item></root>")
steps = testXML.SelectNodes("*/item")
For Each tag In steps

Try
For Each selectedTag In tag
If 1 = 1 Then
Console.WriteLine("In the If Block")
Exit Try
Console.WriteLine("After the Exit Try")
End If
Console.WriteLine("After If Block")
Next

Console.WriteLine("Exited Inner For Loop")

Catch ex As Exception
Console.WriteLine("Test caught: " & ex.Message)

Finally
Console.WriteLine("Test Done")

End Try

Exit For
Next
Catch ex As Exception
Console.WriteLine("Main caught: " & ex.Message)
Finally
Console.WriteLine("Press enter to exit")
Console.ReadLine()
End Try

End Sub


End Module

"David Bayley" <dbayley@spamless.aebacus.com> wrote in message
news:3cdc9b2b@10.1.10.29...
> David Williams wrote:
> > Sorry for the repost, but the first was almost unreadable....
>
> It would also help if you explained what the problem was... but I
> managed to reduce the code further to:
>
> Option Strict On
> Imports System
> Imports System.Collections
> Module Module1
> Sub Main()
> Console.WriteLine("Start")
> Dim items As New ArrayList
> items.Add(New Object())
> Try
> Dim item As Object
> For Each item In items
> Console.WriteLine("Exit Try")
> Exit Try
> Next item
> Console.WriteLine("D'Oh")
> Finally
> Console.WriteLine("Finish")
> End Try
> End Sub
> End Module
>
> Which outputs:
> Start
> Exit Try
> D'Oh
> Finish
>
> The "D'Oh" output does seem like a bad bug, unless I'm missing something
> obvious. The ForEach loop over an IEnumerable collection is required
> (e.g. foreach'ing over an Int32 array works fine, sans D'Oh).
>
> <shrug/>. One solution is to ban the Exit keyword from your code...
> it's as bad as Goto IMO.
>
> --
> David
>
>
>

[Michael Culley]

David,

>I tried the same structures without
> using the XML types and it
> works as expected...

Did you read david's reply?

<bad joke>Anyway, I can see the problem, VB is *trying* to execute a for
loop but you keep interupting it</bad joke>. Seriously, it looks like a bug
to me. If you use exit sub it works correctly.

David B,

> One solution is to ban the Exit keyword from your code...
> it's as bad as Goto IMO.

But the alternatives are worse, try iterating through an array to find a
value without using an Exit

Try also writing a function where there are 10 tests which could result in
the termination of the function. The result is all these nested if
statements where the test and the endif and too far apart hence, making it
difficult to read. I used to agree with you on this one but once I started
to use them I realised how useful they are.

The reason the goto is considered bad is that it is possible enter into the
middle of a block or accidentally jump out of too many blocks. But the Exit
keyword does not suffer these problems.

--
Michael Culley
www.vbdotcom.com

[Patrick Steele [MVP]]

In article <3cdc9b2b@10.1.10.29> (from David Bayley
<dbayley@spamless.aebacus.com>),
> The "D'Oh" output does seem like a bad bug, unless I'm missing something
> obvious. The ForEach loop over an IEnumerable collection is required
> (e.g. foreach'ing over an Int32 array works fine, sans D'Oh).

If you look at the generated IL, VB.NET is placing the for..each loop
inside it's own try/catch block to handle the IDisposable interface of
IEnumerable. Since an Int32 array doesn't need disposing, the code
works with an Int32 array.

The programmers Exit Try actually exit's VB.NET's generated try/catch,
not the programmers. You need to re-arrange logic or use a goto (ack!)
to jump exactly where you want.

--
Patrick Steele
Microsoft .NET MVP

[Thomas Eyde]

So you say VB.Net does not obey the programmers instructions, but choose to
create its own? This must certainly be a bug.

I can agree on the need of re-arrange the logic for readability, but do it
to satisfy the compiler is plain stupid. If I hadn't stumbled across this
post how would I know?

One of my reasons to use a programming language is not to have to read IL,
assembly or whatever.

..thomas

"Patrick Steele [MVP]" <patrick@mvps.org> wrote in message
news:MPG.1749948fa294d27c98992c@news.devx.com...
> If you look at the generated IL, VB.NET is placing the for..each loop
> inside it's own try/catch block to handle the IDisposable interface of
> IEnumerable. Since an Int32 array doesn't need disposing, the code
> works with an Int32 array.
>
> The programmers Exit Try actually exit's VB.NET's generated try/catch,
> not the programmers. You need to re-arrange logic or use a goto (ack!)
> to jump exactly where you want.

[Michael Culley]

> I can agree on the need of re-arrange the logic for readability, but do it
> to satisfy the compiler is plain stupid. If I hadn't stumbled across this
> post how would I know?

Patrick or anyone else never said this wasn't a bug.

--
Michael Culley
www.vbdotcom.com



"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3ceab989$2@10.1.10.29...
> So you say VB.Net does not obey the programmers instructions, but choose
to
> create its own? This must certainly be a bug.
>
> I can agree on the need of re-arrange the logic for readability, but do it
> to satisfy the compiler is plain stupid. If I hadn't stumbled across this
> post how would I know?
>
> One of my reasons to use a programming language is not to have to read IL,
> assembly or whatever.
>
> .thomas
>
> "Patrick Steele [MVP]" <patrick@mvps.org> wrote in message
> news:MPG.1749948fa294d27c98992c@news.devx.com...
> > If you look at the generated IL, VB.NET is placing the for..each loop
> > inside it's own try/catch block to handle the IDisposable interface of
> > IEnumerable. Since an Int32 array doesn't need disposing, the code
> > works with an Int32 array.
> >
> > The programmers Exit Try actually exit's VB.NET's generated try/catch,
> > not the programmers. You need to re-arrange logic or use a goto (ack!)
> > to jump exactly where you want.
>
>
>

[Bo Hunter]

Why does every one that has some trouble with VS.Net
the first thing they say is that they have found a bug.
I think it must be some big high for people to find a
bug in the million lines of code that makeup the software.
99% of the time it is something they have done wrong in the firts place.
I am not being a smart but. I have read alot of post all over the net
and that is the first thing they say Oh I found a major bug in visual studio
.net. The bug thay are talking about is something i have already
delt with and is not a bug.

[Michael Culley]

Are you saying this is not a bug and that this is something david did
wrong???

--
Michael Culley
www.vbdotcom.com



"Bo Hunter" <bovsnet@msn.com> wrote in message news:3cead064$1@10.1.10.29...
>
> Why does every one that has some trouble with VS.Net
> the first thing they say is that they have found a bug.
> I think it must be some big high for people to find a
> bug in the million lines of code that makeup the software.
> 99% of the time it is something they have done wrong in the firts place.
> I am not being a smart but. I have read alot of post all over the net
> and that is the first thing they say Oh I found a major bug in visual
studio
> net. The bug thay are talking about is something i have already
> delt with and is not a bug.

[David Williams]

My intent on posting this kind of information is two fold, and neither has
anything to do with boosting my ego. I posted to 1) Find out if this was
indeed of a bug, or was it just something in the framework that I was not
aware of. To that point, I agree that the title of the post was an
attention getting device. The other reason is to let other people know of
the problem. If they were not aware of it, they might end up spending the
four days that I spent trying find out what I - yes I - did wrong.

David

"Michael Culley" <mike@vbdotcom.com> wrote in message
news:3ceadb7a@10.1.10.29...
> Are you saying this is not a bug and that this is something david did
> wrong???
>
> --
> Michael Culley
> www.vbdotcom.com
>
>
>
> "Bo Hunter" <bovsnet@msn.com> wrote in message
news:3cead064$1@10.1.10.29...
> >
> > Why does every one that has some trouble with VS.Net
> > the first thing they say is that they have found a bug.
> > I think it must be some big high for people to find a
> > bug in the million lines of code that makeup the software.
> > 99% of the time it is something they have done wrong in the firts place.
> > I am not being a smart but. I have read alot of post all over the net
> > and that is the first thing they say Oh I found a major bug in visual
> studio
> > net. The bug thay are talking about is something i have already
> > delt with and is not a bug.
>
>

[Michael Culley]

> four days that I spent trying find out what I - yes I - did wrong.

How is this something that you did wrong?

--
Michael Culley
www.vbdotcom.com

[Patrick Steele [MVP]]

In article <3ceab989$2@10.1.10.29> (from Thomas Eyde
<thomas.eyde@online.no>),
> So you say VB.Net does not obey the programmers instructions, but choose to
> create its own? This must certainly be a bug.

Yes, indeed it is. I never said it wasn't.

> I can agree on the need of re-arrange the logic for readability, but do it
> to satisfy the compiler is plain stupid.

It's unfortunate, but not unheard of. If you look back over the past 20
years or so, I'm sure programmers have had to deal with compiler
"quirks/bugs" on more than one occasion.

--
Patrick Steele
Microsoft .NET MVP

[David Williams]

It was not something that I did wrong. I had assumed that I had, as I was
certain that if any of the code the came out of .NET would be clean of bugs,
it would be the structured error handling. Based on that, now known to be
erroneous, assumption, my code must have been wrong.

"Michael Culley" <mike@vbdotcom.com> wrote in message
news:3ceaecbd@10.1.10.29...
> > four days that I spent trying find out what I - yes I - did wrong.
>
> How is this something that you did wrong?
>
> --
> Michael Culley
> www.vbdotcom.com
>
>