[Mono-bugs] [Bug 52064][Nor] Changed - Exception throwing MUST set the error information (Err object) before throwing the exception
bugzilla-daemon@bugzilla.ximian.com
bugzilla-daemon@bugzilla.ximian.com
Fri, 23 Jul 2004 02:38:18 -0400 (EDT)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by kjambunathan@novell.com.
http://bugzilla.ximian.com/show_bug.cgi?id=52064
--- shadow/52064 2004-07-23 01:54:36.000000000 -0400
+++ shadow/52064.tmp.17601 2004-07-23 02:38:18.000000000 -0400
@@ -1,13 +1,13 @@
Bug#: 52064
Product: Mono: Compilers
Version: unspecified
OS: unknown
OS Details:
-Status: NEW
-Resolution:
+Status: RESOLVED
+Resolution: INCOMPLETE
Severity: Unknown
Priority: Normal
Component: Basic
AssignedTo: skumar1@novell.com
ReportedBy: rafaelteixeirabr@hotmail.com
QAContact: mono-bugs@ximian.com
@@ -80,6 +80,180 @@
The Err object should retrieve it's information from the thrown
Exception just in time and should not be set by the exception itself.
Exceptions are internal CLR objects, but the Err object is
Microsoft.VisualBasic specific...
+
+------- Additional Comments From kjambunathan@novell.com 2004-07-23 02:38 -------
+Let's reserve this support for fixing the runtime.
+
+mbas support for the Error Objects and Error Numbers will be taken
+separately not as part of this bug.
+
+
+Some of Rafael's comments in the mono-vb list.
+
+Hi Jambunathan,
+
+Well I did not follow it: It isn't resolved.
+
+More: We need to make it into nunit tests for the corresponding
+parts in MS.VB.DLL, and also compiler test sources to guarantee
+compatible behaviour.
+
+Maybe you are suggesting to open a series of more specific bug
+cases, to match smaller units of work. That is acceptable.
+
+Just to say what we are after...
+
+Refining the test code that Jochen has put there to something like:
+
+<snip>
+ Private Sub ThrowIt(ByVal exc As Exception)
+ Try
+ Throw exc
+ Catch ex As Exception
+ If Err.Number <> 0 Then WriteLine("ErrDescr= " &
+Err.Description)
+ If Err.Number <> 0 Then WriteLine("ErrNo= " & Err.Number)
+ WriteLine("Exception= " & ex.ToString())
+ WriteLine("-------------------------")
+ End Try
+ End Sub
+
+ Private Sub ErrorIt(errornum as Integer)
+ Try
+ Err.Raise(errornum)
+ Catch ex As Exception
+ If Err.Number <> 0 Then WriteLine("ErrDescr= " &
+Err.Description)
+ If Err.Number <> 0 Then WriteLine("ErrNo= " & Err.Number)
+ WriteLine("Exception= " & ex.ToString())
+ WriteLine("-------------------------")
+ End Try
+ End Sub
+
+ Private Sub ErrObjTests()
+ ThrowIt(New ArgumentOutOfRangeException("blah")) ' --> No. 5
+ ThrowIt(New OverflowException) ' --> No. 6 default
+description
+ ThrowIt(New OverflowException("blah")) ' --> No. 6
+ ThrowIt(New Exception("WhatIsIt?")) ' --> No. 5
+ ErrorIt(4)
+ ErrorIt(5)
+ ErrorIt(6)
+ End Sub
+</snip>
+
+I got the following results:
+<results>
+ErrDescr= Specified argument was out of the range of valid values.
+Parameter name: blah
+ErrNo= 5
+Exception= System.ArgumentOutOfRangeException: Specified argument
+was out of
+the range of valid values.
+Parameter name: blah
+ at WindowsApplication1.Form1.ThrowIt(Exception exc) in
+C:\Dev\WindowsApplication1\Form1.vb:line 127
+-------------------------
+ErrDescr= Arithmetic operation resulted in an overflow.
+ErrNo= 6
+Exception= System.OverflowException: Arithmetic operation resulted
+in an
+overflow.
+ at WindowsApplication1.Form1.ThrowIt(Exception exc) in
+C:\Dev\WindowsApplication1\Form1.vb:line 127
+-------------------------
+ErrDescr= blah
+ErrNo= 6
+Exception= System.OverflowException: blah
+ at WindowsApplication1.Form1.ThrowIt(Exception exc) in
+C:\Dev\WindowsApplication1\Form1.vb:line 127
+-------------------------
+ErrDescr= WhatIsIt?
+ErrNo= 5
+Exception= System.Exception: WhatIsIt?
+ at WindowsApplication1.Form1.ThrowIt(Exception exc) in
+C:\Dev\WindowsApplication1\Form1.vb:line 127
+-------------------------
+ErrDescr= Application-defined or object-defined error.
+ErrNo= 4
+Exception= System.Exception: Application-defined or object-defined
+error.
+ at Microsoft.VisualBasic.ErrObject.Raise(Int32 Number, Object
+Source,
+Object Description, Object HelpFile, Object HelpContext)
+ at WindowsApplication1.Form1.ErrorIt(Int32 errornum) in
+C:\Dev\WindowsApplication1\Form1.vb:line 138
+-------------------------
+ErrDescr= Procedure call or argument is not valid.
+ErrNo= 5
+Exception= System.ArgumentException: Procedure call or argument is
+not
+valid.
+ at Microsoft.VisualBasic.ErrObject.Raise(Int32 Number, Object
+Source,
+Object Description, Object HelpFile, Object HelpContext)
+ at WindowsApplication1.Form1.ErrorIt(Int32 errornum) in
+C:\Dev\WindowsApplication1\Form1.vb:line 138
+-------------------------
+ErrDescr= Overflow.
+ErrNo= 6
+Exception= System.OverflowException: Overflow.
+ at Microsoft.VisualBasic.ErrObject.Raise(Int32 Number, Object
+Source,
+Object Description, Object HelpFile, Object HelpContext)
+ at WindowsApplication1.Form1.ErrorIt(Int32 errornum) in
+C:\Dev\WindowsApplication1\Form1.vb:line 138
+-------------------------
+</results>
+
+Well I don't think mbas compiles this right yet. See, VB.NET
+compiler need
+to add some extra code in catch blocks to make the exception
+available in
+Err, vbc does this inside ThrowIt catch block
+
+ IL_0009: dup
+ IL_000a: call void
+[Microsoft.VisualBasic]
+Microsoft.VisualBasic.CompilerServices.ProjectData::SetProjectError
+(class
+[mscorlib]System.Exception)
+
+
+So even if this same program when compiled with vbc and run in mono
+using
+our MS.VB.DLL, won't say the right things, because I'm not sure if
+the
+Microsoft.VisualBasic.CompilerServices.ProjectData::SetProjectError
+method
+is correctly implemented and interacts with the implemented
+ErrObject in the
+proper way (I don't have access to a mono environment and/or source
+where I
+am for the next hours so I can't check it for correctness myself).
+
+So as it stands, please prove me wrong or reopen or decompose the
+bug case.
+
+Also we aren't even scratching the whole mess as "On Error"
+processing isn't
+being tackled yet. Think of the ill-conceived but common pattern
+among VB
+developers "On Error Resume Next / do something / check Err if
+needed (after
+the fact) / ... similar statements like the last two (n-times)"
+
+Thanks,
+
+
+Rafael "Monoman" Teixeira
+Mono Hacker since 16 Jul 2001 - http://www.go-mono.org/
+MonoBrasil Founding Member - Membro Fundador do MonoBrasil
+http://monobrasil.softwarelivre.org
+English Blog: http://monoblog.blogspot.com/
+Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/
+
+