Err.Number (VB6 versus C#)

Question

I've used Artinsoft's VB6 to .NET wizard to convert a VB6 application to C# and I'm getting an upgrade warning in any place where Err.Number was previously used;

//UPGRADE_WARNING: (2081) Err.Number has a new behavior.

The converted code is referring to;

Microsoft.VisualBasic.Information.Err().Number

I haven't had any luck finding out what the difference is. Does anyone know what it might be, or is it safe to ignore this warning?

UPDATE

For anyone who stumbles across this question in the future - a word of warning; It is NOT safe to continue using Err.Number in a C# .NET application. The property is still available, however it is not populated after errors as expected. The only case in which it is populated as expected is if the error comes from a COM component.

Normal errors e.g. DB access, IO operations etc. will not give any value to Err().Number, and so its use must be refactored unfortunately.

Strangely enough, in VB .NET, it still does work as expected, so perhaps this is something to keep in mind when making a decision on the target language for conversion.

Answer 1

Description of VB6 Err.Number from October 2000 MSDN:

Returns or sets a numeric value specifying an error. Number is the Err object's default property. Read/write.

Description of VB.NET Err.Number from MSDN:

Returns or sets a numeric value specifying an error. Read/write.

The remarks from the Oct 2000 MSDN are copied word for word in the online version for VB.NET including the example. Doesn't seem to be anything different between the two.

Answer 2

Maybe the numbers used have changed?

Answer 3

Hi, basically VB.NET has support for the Err.Number property, and it works pretty much the same as in VB6, however when upgrading to C# the Microsoft.VisualBasic.Information.Err().Number is not populated correctly, and you should not rely on it.

The only scenario where the error number is set for sure, is when the error is generated by a COM interop component, in which case you can check the error number in the InnerException member of the exception.

You should convert all the Err.Number usages for .NET exceptions, and modify the logic to behave correctly with structured error handling.

regards