2014-04-03, 08:20
NOTE: Edge case unobserved task exception when cancelling a load.
I've picked up another edge case scenario where cancelling a Load may result in an unobserved task exception being thrown, which will cause Video Explorer to restart itself.
That happens because of the way the Cancel is implemented to immediately cancel the entire loading sequence when you click the Cancel button, without delay.
Each Movie is loading on a separate thread with multiple threads running and under normal circumstances the control code sits and waits for each of those threads to complete their work and catches any errors thrown by any thread and handles the errors gracefully.
If you Cancel, however, the calling code stops listening and any threads still running effectively become orphaned and will complete in the background quickly and the results of their work will be discarded.
The problem is, if you cancel, and one of those orphaned threads that is still running then throws an exception error because of a bad file it can't load, that error is no longer caught and handled by the calling code gracefully and so the application has to deal with it in a more generic way, and it actually crashes the app.
It's a balancing act between performance and stability again, but I might have to change it to still wait for any work already scheduled on other threads to complete before I actually Cancel completely, to guarantee that any exception errors are caught and handled gracefully.
Looking at it now.
I've picked up another edge case scenario where cancelling a Load may result in an unobserved task exception being thrown, which will cause Video Explorer to restart itself.
That happens because of the way the Cancel is implemented to immediately cancel the entire loading sequence when you click the Cancel button, without delay.
Each Movie is loading on a separate thread with multiple threads running and under normal circumstances the control code sits and waits for each of those threads to complete their work and catches any errors thrown by any thread and handles the errors gracefully.
If you Cancel, however, the calling code stops listening and any threads still running effectively become orphaned and will complete in the background quickly and the results of their work will be discarded.
The problem is, if you cancel, and one of those orphaned threads that is still running then throws an exception error because of a bad file it can't load, that error is no longer caught and handled by the calling code gracefully and so the application has to deal with it in a more generic way, and it actually crashes the app.
It's a balancing act between performance and stability again, but I might have to change it to still wait for any work already scheduled on other threads to complete before I actually Cancel completely, to guarantee that any exception errors are caught and handled gracefully.
Looking at it now.
