Description
VistaFolderBrowserDialog.ShowDialog()
can fail with deferent types of exceptions when we create a new instance VistaFolderBrowserDialog
and set SelectedPath
property.
I'm using this Dialog in a scenario when the user is able to manually input the path in text-block or call this dialog and select the correct path through it. I have some base validation on this text block, to ensure that the input string is a fully qualified DOS path string or correct network path. That's why I set SelectedPath
with this user inputted string as a SelectedPath
of the dialog and expect that it will try to find the existing folder or use an empty string in another case.
My assumption, that this dialog should use exception safely check for SelectedPath
string or use a null in another case.
Steps to reproduce
- I used MainWindow.xaml sample and change it a little to allow easily reproduce this case in
Ookii.Dialogs.Wpf.Sample
private void ShowFolderBrowserDialog()
{
var selectedPath = @"C:\..\";
var dialog = new VistaFolderBrowserDialog(){SelectedPath = selectedPath };
dialog.Description = "Please select a folder.";
dialog.UseDescriptionForTitle = true; // This applies to the Vista style dialog only, not the old dialog.
...
This var selectedPath
will produce Win32Exception during dialog.ShowDialog(this)
calling. And it will be raised from public static Interop.IShellItem CreateItemFromParsingName(string path)
- Another case is
PathToLongException
that can be thrown if SelectedPath length exceeds the maximum allowed folder name or full pathname length. (just set selectedPath with really huge string). orArgumentException
(some incorrect chars in SelectedPath) This happens because ofPath.GetDirectoryName(_selectedPath)
inSetDialogProperties()
method.
Path.GetDirectoryName()
and Path.GetFileName()
are not exception safe like Directory.Exists()
. (see https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getdirectoryname?view=net-6.0 and https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getfilename?view=net-6.0 for details).
Looks like it's better to cover their usages with try/catch block and treat SelectedPath
as an empty string in case of Win32Exception
, PathToLongException
, and ArgumentException
to hold this case