Correct disposal implementation for exception widget

[michelkaporin]

I believe the reason for the the exception is that _viewZone was disposed meanwhile it was scheduled to relayout. Added null check for _viewZone. Correct me if I am wrong.

Fixes #22607

[msftclas]

@michelkaporin,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

[isidorn]

@michelkaporin the issue here is that you are using a scheduler with a 50ms which can happen after the widget is disposed.
I would prefer a proper fix which is that you cancel and dispose the scheduler in your dipose method(or just add the scheduler in the this_disposabels).

[michelkaporin]

Pushed the proper change, thanks for the advice @isidorn!

[isidorn]

@michelkaporin I think you misunderstood me, you do not need to care about disposing disposables, that should be nicely done by the super class.
You shuold simply add your scheduler to the disposables and everything should be dispoed perfectly

[michelkaporin]

@isidorn In fact it is already added in the constructor.
https://github.com/michelkaporin/vscode/blob/be3d0cf945bbad51ade31d81c760e90307c633b3/src/vs/workbench/parts/debug/browser/exceptionWidget.ts#L26

My second commit is anyway redundant then. In addition, when the dispose method is called on the scheduler, it cancels it before disposing.

I've looked at the code flow again and it seems that the problem lies not in the fact that _viewZone was disposed and scheduler not, as I thought initially. It seems to be that the scheduler was created and called before the _viewZone was instantiated with zoneWidget.show() method. I will revert the last commit back to be3d0cf which looks like a correct fix for me in this scenario, do you agree?

[isidorn]

@michelkaporin sometimes it is easier to communicate in code, here's what I meant 1bd0389

The difference that you already have a listener to schedule the scheduler to be disposed, but not the scheduler itself. The difference is the following

An event happens and you schedule
20 ms later you get diposed - you dipose the listener but the scheduler is still alive and kicking
30 ms later scheduler kicks in and does stuff on on invalid object

[michelkaporin]

@isidorn Makes sense now. Sorry, I was wrongly assuming that I am disposing the scheduler, whereas it was a listener. Thanks for explanation.

[isidorn]

@michelkaporin no worries, welcome.