public int Slno
{
get { return _Slno; }
set { this._Slno = value; }
}

public int MSl3no
{
get { return _MSl3no; }
set { this._MSl3no = value; }
}

public string PartCode
{
get{return _PartCode;}
set{thiss._PartCode=value;}
}

public string PartDesc
{
get{return _PartDescription;}
set{thiss._PartDescription=value;}
}

public float Qty
{
get{return __Qty;}
set{thiss.__Qty=value;}
}

public UOM Uom
{
get{return _UOM;}
set{thiss._UOM=value;}
}
}what error in this?

I’m not a VB.Net guru, but it looks like this is a difference in the way the VB compiler and the C# compiler treat code.

I wrote two simple programs and opened them up in ILDASM.

C#

static void Main(string[] args)
{
int n1 = 5;
int n2 = 0;
int result = n1 / n2;
}

VB.Net

Sub Main()
Dim n1 As Integer = 5
Dim n2 As Integer = 0
Dim result As Integer = n1 / n2
End Sub

They appear to do the same thing, but under the covers, they don’t. When I run ILDasm against C#, I get this as a partial result.

.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 10 (0xa)
.maxstack 2
.locals init ([0] int32 n1,
[1] int32 n2,
[2] int32 result)
IL_0000: nop
IL_0001: ldc.i4.5
IL_0002: stloc.0
IL_0003: ldc.i4.0
IL_0004: stloc.1
IL_0005: ldloc.0
IL_0006: ldloc.1
IL_0007: div
IL_0008: stloc.2
IL_0009: ret
} // end of method Program::Main

The both parameters are loaded as integers, and the division is returned as an integer.

In VB.Net, however, the code disassembles to this:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 19 (0×13)
.maxstack 2
.locals init ([0] int32 n1,
[1] int32 n2,
[2] int32 result)
IL_0000: nop
IL_0001: ldc.i4.5
IL_0002: stloc.0
IL_0003: ldc.i4.0
IL_0004: stloc.1
IL_0005: ldloc.0
IL_0006: conv.r8
IL_0007: ldloc.1
IL_0008: conv.r8
IL_0009: div
IL_000a: call float64 [mscorlib]System.Math::Round(float64)
IL_000f: conv.ovf.i4
IL_0010: stloc.2
IL_0011: nop
IL_0012: ret
} // end of method Module1::Main

See the conv.r8s in there, and also the call to System.Math that is rounding to a float64? For whatever reason, VB.Net has decided that divisions should be done with floats. I’ve stated in other posts that C# and VB.Net are not as equivalent as Microsoft says they are, and this is another great example.

An erie twist on this is the errors that are raised. Because of the way these variables are treated, C# (correctly) returns a divide by zero error, while VB.Net throws an arithmatic overflow!

Console.WriteLine(“Enter the two numbers and the operator”)

n1 = Console.ReadLine
n2 = Console.ReadLine
op = Console.ReadLine

Console.WriteLine(“Division ——>” & (n1 / n2))
Console.ReadLine()
End Sub
End Module

#########################################################

I am beginner in .net programming. I am facing the same problem here. You said that using “double” gives the output as “infinity”. But I used “integer” ( which is decimal, I hope so) and I got the same one, “infinity”. So please help me out.

Do you know if the “Release mode” treats numbers differently from the “Debug mode”?

I have to do a conversion from char* to double and it does it correctly in the “Debug mode” but incorrectly in the “Release mode”.

Example:
– Debug: 9.0377972222222
– Release: 9.0397277777778

Santi24 needs help! Please!

getErrorLineNo() function realy helped me to get what I want. Thanks,
I would like to add few of my code which would be more helpfull in this prospect. Here, you get the filename, LineNumber and the MethodName where the Exception Orginated.

public static void LogException(Exception ex)
{
System.Diagnostics.StackTrace Trace = new System.Diagnostics.StackTrace(ex, true);
System.Diagnostics.StackFrame frame = Trace.GetFrame(Trace.FrameCount – 1);
string FileName = frame.GetMethod().ToString();
string MethodName = frame.GetMethod().ToString();
string LineNumber = frame.GetFileLineNumber().ToString();
}

Thanks,
Franklin

Two thinks which were really helpful:
1. You mentioned the IL code using ILDasm
2. The link given to scott’s article.

namaste!
Atreya A