-1

I'm having a very weird behaviour from this method:

    public T NavigateTo<T>() where T : Page
    {
        SetPage<T>();

        Console.Clear();
        CurrentPage.Display();

        return CurrentPage as T;
    }

From: https://github.com/uta-org/EasyConsole/blob/master/EasyConsole/Program.cs#L106

The problem is that when Console.Clear() is reached I continue executing (pressing F10) the scope just exits from the method.

...

As you can see, as soon as I press F10 (step over) console is displayed again (this means that the breakpoint execution ended).

Why is this happening? And what is returning this method? Because I'd expected a 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)))
    {
    }

From: https://github.com/uta-org/QuickFork/blob/eaf8f0a65af75e74015a1a1e168d98ad65d9e472/QuickFork.Shell/MainPage.cs#L21

I do this as author requested on README. And as you can see I'm setting DoLinking property, and this is not Nullable. (The bug I'm having is that DoLinking is unnasigned so my workflow is not executing as I expected).

I'm experiencing this on Debug and Release build. I'm on .NET 4.6.1.

EDIT:

I didn't realize about the Intelisense IOException. But I put toggled this exception on the Exception Settings window:

...

And the suggested code by @stimms's answer:

...

But this is more weird even because any exception is thrown.

z3nth10n
  • 2,341
  • 2
  • 25
  • 49

2 Answers2

1

There are certain scenarios under which console.clear will throw IOException.

I'd bet that Console.Clear is throwing an IOException that isn't being caught. The official guidance on Console.Clear (https://learn.microsoft.com/en-us/dotnet/api/system.console.clear?view=netframework-4.7.2) is that you should warp its use in a try/catch block.

public T NavigateTo<T>() where T : Page
{
    SetPage<T>();

    try{
      Console.Clear();
    }catch(IOException ex){
      //do something
    }
    CurrentPage.Display();

    return CurrentPage as T;
}
stimms
  • 42,945
  • 30
  • 96
  • 149
  • I tried what you suggested but this leaded me to a stranger behaviour. Look my edited question above please. – z3nth10n Jan 23 '19 at 16:35
0

Despite the two downvotes I received, I still believe (and people, as I can see, don't understand it) this is a bug (so I created an issue on dotnet/roslyn repo).

So, to solve it, I changed DoLinking variable from ForkSyncing class to a static one.

And then, I did the following:

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))));

So, if I set it before I call NavigateTo<T>() I won't have this problem.

z3nth10n
  • 2,341
  • 2
  • 25
  • 49