This can't be true

  • Thread starter Thread starter Uri Dor
  • Start date Start date
U

Uri Dor

try running this C# code in VS.NET 2003:

using System;

namespace ExitCode
{
class MainClass
{
static int Main(string[] args)
{
return 7;
}
}
}

run it under the debugger, and what do you get?
The program '[4552] ExitCode.exe' has exited with code 0 (0x0).

see? zero, not seven. Is this a bug or what?
 
I tried again, this time from the command line, and checked
%ERRORLEVEL%. This way I do get the correct exit code - so this is an
IDE bug?
 
no offense intended to the repliers, but could I get an answer from a
MSFT employee ?

Uri said:
I tried again, this time from the command line, and checked
%ERRORLEVEL%. This way I do get the correct exit code - so this is an
IDE bug?

Uri said:
try running this C# code in VS.NET 2003:

using System;

namespace ExitCode
{
class MainClass
{
static int Main(string[] args)
{
return 7;
}
}
}

run it under the debugger, and what do you get?
The program '[4552] ExitCode.exe' has exited with code 0 (0x0).

see? zero, not seven. Is this a bug or what?
 
Anubhav is right. The program executed and ended without error, so the
exit code is 0. I don't think that you need a MS employee to explain
that.
 
Hello Uri,

Can it be any MSFT employee? Perhaps maybe one from marketing knows the answer
to this better than people that are using the technology on a daily basis.

Let me reiterate: The program executed without error, so it returns with
a 0. If you need to modify the return value of the program, use Environment.Exit(int)

--
Matt Berther
http://www.mattberther.com
no offense intended to the repliers, but could I get an answer from a
MSFT employee ?

Uri said:
I tried again, this time from the command line, and checked
%ERRORLEVEL%. This way I do get the correct exit code - so this is an
IDE bug?

Uri said:
try running this C# code in VS.NET 2003:

using System;

namespace ExitCode
{
class MainClass
{
static int Main(string[] args)
{
return 7;
}
}
}
run it under the debugger, and what do you get?
The program '[4552] ExitCode.exe' has exited with code 0 (0x0).
see? zero, not seven. Is this a bug or what?
 
Let's ask the MS marketing guy, maybe he can spit some gibberish that may
sound correct :-)

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________


Matt Berther said:
Hello Uri,

Can it be any MSFT employee? Perhaps maybe one from marketing knows the
answer to this better than people that are using the technology on a daily
basis.

Let me reiterate: The program executed without error, so it returns with a
0. If you need to modify the return value of the program, use
Environment.Exit(int)

--
Matt Berther
http://www.mattberther.com
no offense intended to the repliers, but could I get an answer from a
MSFT employee ?

Uri said:
I tried again, this time from the command line, and checked
%ERRORLEVEL%. This way I do get the correct exit code - so this is an
IDE bug?

Uri Dor wrote:

try running this C# code in VS.NET 2003:

using System;

namespace ExitCode
{
class MainClass
{
static int Main(string[] args)
{
return 7;
}
}
}
run it under the debugger, and what do you get?
The program '[4552] ExitCode.exe' has exited with code 0 (0x0).
see? zero, not seven. Is this a bug or what?
 
let me reiterate this to all repliers (so far):
I tried running the code from the command line, and checked
%ERRORLEVEL%. This way I do get the correct exit code (by this I mean 7,
not 0).
The correct exit code is 7, not 0, because that's what my code returns
(either by return 7 or by Environment.Exit(7), which are the same).
The IDE, however, ignores the process exit code and shows 0, which
although being a common convention for a successful process exit code,
was not the actual process exit code.
If anyone still thinks 0 is the right value for the IDE to show - I'm
sorry, I don't think I can make this any clearer.

Uri said:
no offense intended to the repliers, but could I get an answer from a
MSFT employee ?

Uri said:
I tried again, this time from the command line, and checked
%ERRORLEVEL%. This way I do get the correct exit code - so this is an
IDE bug?

Uri said:
try running this C# code in VS.NET 2003:

using System;

namespace ExitCode
{
class MainClass
{
static int Main(string[] args)
{
return 7;
}
}
}

run it under the debugger, and what do you get?
The program '[4552] ExitCode.exe' has exited with code 0 (0x0).

see? zero, not seven. Is this a bug or what?
 
Pat A said:
Anubhav is right. The program executed and ended without error, so the
exit code is 0. I don't think that you need a MS employee to explain
that.

No, Anubhav is *not* right. The return value from Main is used as the
exit code if you use the version which returns an int.

For instance, try this:

using System;

class Test
{
static int Main()
{
return 5;
}
}

Run that from the command line, and then type

echo %ERRORLEVEL%

- it will display 5.

That's one of the supported ways of exiting a program with a specific
exit code. It's unfortunate that the debugger doesn't seem to support
it properly.
 
Uri Dor said:
try running this C# code in VS.NET 2003:

using System;

namespace ExitCode
{
class MainClass
{
static int Main(string[] args)
{
return 7;
}
}
}

run it under the debugger, and what do you get?
The program '[4552] ExitCode.exe' has exited with code 0 (0x0).

see? zero, not seven. Is this a bug or what?

I suspect it's a limitation of the debugger. It happens to me too, just
so you know you're not going mad :)

My guess is that the debugger is intercepting things, and resetting the
exit code to show that *it* exited cleanly. Not terribly helpful though
:(
 
Thanks, Jon, from the depth of my remaining sanity :-)

Uri Dor said:
try running this C# code in VS.NET 2003:

using System;

namespace ExitCode
{
class MainClass
{
static int Main(string[] args)
{
return 7;
}
}
}

run it under the debugger, and what do you get?
The program '[4552] ExitCode.exe' has exited with code 0 (0x0).

see? zero, not seven. Is this a bug or what?


I suspect it's a limitation of the debugger. It happens to me too, just
so you know you're not going mad :)

My guess is that the debugger is intercepting things, and resetting the
exit code to show that *it* exited cleanly. Not terribly helpful though
:(
 
Back
Top