Ok, I had to add to this. First off, as a user, I would prefer that any
app I use have almost always have a retry button. Even in cases where
the file or directory couldn't be found. What if I had forgotten to
perform some action which would've caused the file or directory to exist
before I clicked the button? Then a Retry button would be quite
helpful. I can do what I forgot to do, the file then exists, and then I
can click Retry, then the app would find it this time. So "Retry" on
FileNotFoundException and DirectoryNotFoundException can actually make a
lot of sense.
Second, I would like to say that there are some cases where you might
want to catch Exception when trying to open a file. It's pretty much
guaranteed that if an Exception of any type is thrown while you're
trying to open a file, then the file couldn't be opened. What if that's
all you need to know? For example, what if this file isn't critical,
and a failure to open it just means that your app can go on without it?
Also, is there something wrong with catching Exception and then showing
a message based on its type, with some sort of an "Unknown Error"
message being shown if it's a totally unexpected Exception? Maybe the
task of choosing a message for the Exception can be performed by some
function.
- Seth Sticco
Peter Ritchie wrote:
Off the top of my head:
* 'The file "filename" already exists.' is sufficient for your users when
you try use FileMode.CreateNew? I would want to ask the user if they wish
to overwrite so they don't have to open Windows Explorer and delete the
file.
* 'Access to path "filename" is denied' is sufficient for your users for
*both* files marked as read-only and files they don't have access to via
ACL. The user can do something if the read-only bit is set; they can't if
their Admin has denied them access via ACL.
* ex.Message is not localized. If I bought a Spanish version of the
software running in English Windows, I still want to see Spanish messages.
* ArgumentNullException, ArgumentOutOfRangeException: these would provide
useful messages.
* A "Retry" button would be nice with file access attempts. It would be
hard to decide whether "Retry" is an option without knowing more detail
about the exception. "Retry" on FileNotFoundException,
DirectoryNotFoundException, PathTooLongException, or ArgumentException
just doesn't make sense.
http://www.peterRitchie.com/
On Mon, 19 Sep 2005 09:57:44 -0400, Eames, Andrew <[EMAIL PROTECTED]>
wrote:
You put up a MessageBox showing ex.Message - in response to the user
typing in a filename that you can't open
In fact this is a good case in point where you will be more robust to
the CLR adding a new exception, not less
Andrew
===================================
This list is hosted by DevelopMentor? http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
