On Tue, 10 Mar 2026 22:32:15 GMT, Nir Lisker <[email protected]> wrote:
>> Good point, though navigating up the file hierarchy might end up somewhere >> completely unrelated or where the user cannot access - "C:/" or "/" or >> "/mnt/" >> >> It might be safer to fall back to the app's current directory (and the app >> can always implement alternative behavior by checking the initial dir before >> invoking the file chooser). > >> and the app can always implement alternative behavior by checking the >> initial dir before invoking the file chooser > > I'm not sure it can because the dir might be deleted between the check and > the file chooser invocation. > >> The right behavior should be to open the dialog using the current directory >> (ignoring the error), and let the user deal with it. > > A fallback directory makes more sense to me, however, we need one that we can > guarantee the existence and access of. The current application directory > sounds like a good bet. > > We can also emit a warning that the initial directory was not found, but I > doubt it'd be helpful. Throwing an exception when the initial directory is not accessible for any reason is not a useful API. This requires the caller to _always_ catch the potential exception, and try to show the dialog again with a fallback folder (or `null`). In the worst case, this means that the application is broken because the dialog can't be shown and the user can't proceed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2101#discussion_r2914877377
