Console.Clear() 停止方法执行(未达到 IOException)
Console.Clear() stops method execution (IOException is not reached)
我从这个方法中得到了一个非常奇怪的行为:
public T NavigateTo<T>() where T : Page
{
SetPage<T>();
Console.Clear();
CurrentPage.Display();
return CurrentPage as T;
}
发件人:https://github.com/uta-org/EasyConsole/blob/master/EasyConsole/Program.cs#L106
问题是,当达到 Console.Clear()
时,我继续执行(按 F10)范围只是从方法中退出。
如你所见,我一按F10
(step over),console 又出现了(这意味着断点执行结束)。
为什么会这样?什么返回这个方法?因为我期待 NullReferenceException
:
public MainPage(Program program)
: base("Main Page", program,
new Option("Fork Syncing (complete process)", () => program.NavigateTo<ForkSyncing>().DoLinking = null),
new Option("Fork Syncing (only cloning)", () => program.NavigateTo<ForkSyncing>().DoLinking = true),
new Option("Fork Syncing (only linking)", () => program.NavigateTo<ForkSyncing>().DoLinking = false),
new Option("Exit", () => Environment.Exit(0)))
{
}
我按照作者在 README 中的要求进行了此操作。如您所见,我正在设置 DoLinking 属性,这不是 Nullable。 (我遇到的错误是 DoLinking 未签名,所以我的工作流没有按预期执行)。
我在调试和发布版本中遇到了这个问题。我在 .NET 4.6.1.
编辑:
我没有意识到 Intelisense IOException。但是我在异常设置 window:
上切换了这个异常
@stimms 的回答建议的代码:
但这更奇怪,因为抛出了任何异常。
在某些情况下 console.clear 会抛出 IOException。
我敢打赌 Console.Clear 正在抛出未被捕获的 IOException
。 Console.Clear (https://docs.microsoft.com/en-us/dotnet/api/system.console.clear?view=netframework-4.7.2) 的官方指导是你应该在 try/catch 块中扭曲它的使用。
public T NavigateTo<T>() where T : Page
{
SetPage<T>();
try{
Console.Clear();
}catch(IOException ex){
//do something
}
CurrentPage.Display();
return CurrentPage as T;
}
尽管我收到了两次反对票,但我仍然相信(正如我所见,人们并不理解)这是一个错误(所以我在 dotnet/roslyn repo
上创建了一个问题)。
所以,为了解决这个问题,我将 DoLinking
变量从 ForkSyncing
class 更改为静态变量。
然后,我做了以下事情:
AddPage(new MainPage(this,
new Option("Fork Syncing (complete process)", () =>
{
ForkSyncing.DoLinking = null;
NavigateTo<ForkSyncing>();
}),
new Option("Fork Syncing (only cloning)", () =>
{
ForkSyncing.DoLinking = true;
NavigateTo<ForkSyncing>();
}),
new Option("Fork Syncing (only linking)", () =>
{
ForkSyncing.DoLinking = false;
NavigateTo<ForkSyncing>();
}),
new Option("Exit", () => Environment.Exit(0))));
所以,如果我在调用 NavigateTo<T>()
之前设置它,我就不会有这个问题。
我从这个方法中得到了一个非常奇怪的行为:
public T NavigateTo<T>() where T : Page
{
SetPage<T>();
Console.Clear();
CurrentPage.Display();
return CurrentPage as T;
}
发件人:https://github.com/uta-org/EasyConsole/blob/master/EasyConsole/Program.cs#L106
问题是,当达到 Console.Clear()
时,我继续执行(按 F10)范围只是从方法中退出。
如你所见,我一按F10
(step over),console 又出现了(这意味着断点执行结束)。
为什么会这样?什么返回这个方法?因为我期待 NullReferenceException
:
public MainPage(Program program)
: base("Main Page", program,
new Option("Fork Syncing (complete process)", () => program.NavigateTo<ForkSyncing>().DoLinking = null),
new Option("Fork Syncing (only cloning)", () => program.NavigateTo<ForkSyncing>().DoLinking = true),
new Option("Fork Syncing (only linking)", () => program.NavigateTo<ForkSyncing>().DoLinking = false),
new Option("Exit", () => Environment.Exit(0)))
{
}
我按照作者在 README 中的要求进行了此操作。如您所见,我正在设置 DoLinking 属性,这不是 Nullable。 (我遇到的错误是 DoLinking 未签名,所以我的工作流没有按预期执行)。
我在调试和发布版本中遇到了这个问题。我在 .NET 4.6.1.
编辑:
我没有意识到 Intelisense IOException。但是我在异常设置 window:
上切换了这个异常@stimms 的回答建议的代码:
但这更奇怪,因为抛出了任何异常。
在某些情况下 console.clear 会抛出 IOException。
我敢打赌 Console.Clear 正在抛出未被捕获的 IOException
。 Console.Clear (https://docs.microsoft.com/en-us/dotnet/api/system.console.clear?view=netframework-4.7.2) 的官方指导是你应该在 try/catch 块中扭曲它的使用。
public T NavigateTo<T>() where T : Page
{
SetPage<T>();
try{
Console.Clear();
}catch(IOException ex){
//do something
}
CurrentPage.Display();
return CurrentPage as T;
}
尽管我收到了两次反对票,但我仍然相信(正如我所见,人们并不理解)这是一个错误(所以我在 dotnet/roslyn repo
上创建了一个问题)。
所以,为了解决这个问题,我将 DoLinking
变量从 ForkSyncing
class 更改为静态变量。
然后,我做了以下事情:
AddPage(new MainPage(this,
new Option("Fork Syncing (complete process)", () =>
{
ForkSyncing.DoLinking = null;
NavigateTo<ForkSyncing>();
}),
new Option("Fork Syncing (only cloning)", () =>
{
ForkSyncing.DoLinking = true;
NavigateTo<ForkSyncing>();
}),
new Option("Fork Syncing (only linking)", () =>
{
ForkSyncing.DoLinking = false;
NavigateTo<ForkSyncing>();
}),
new Option("Exit", () => Environment.Exit(0))));
所以,如果我在调用 NavigateTo<T>()
之前设置它,我就不会有这个问题。