Proper way to handle UnauthorizedAccessException

[cbmeeks]

I have a project that gathers a list of directories on a computer.
When it hits hidden, protected directories (like c:\system volume
information) it throws an UnauthorizedAccessException error.

As a quick fix, I've captured that error in a try/catch block and just
ignored it (including ignoring the directory).

I don't like kludging like this. Is there a better way?

Thanks

-cbmeeks

 

[Marc Gravell]

That doesn't sound like a kludge to me. You are catching a specific
error for a known, expected reason, and reacting accordingly. Sounds
fine IMO.

Marc

 

[cbmeeks]

That doesn't sound like a kludge to me. You are catching a specific
error for a known, expected reason, and reacting accordingly. Sounds
fine IMO.

Marc

Thanks.

I really didn't see any other way but I wanted to make sure.

Thanks again.

-cbmeeks

 

[Guest]

If there's nothing you can do, I would agree with Marc: you're handling the
exception.

Depending on the acces violation you could inform the user and ask for
another username/password; but then you'd have to deal with impersonation,
etc.

 

[Peter Duniho]

Thanks.

I really didn't see any other way but I wanted to make sure.

I agree with Marc. IHMO, the reason is *seems* kludgy is probably that
you're used to checking for error return codes and taking appropriate
action based on that. I mean, I don't know what your experience is, but
that's how it is for me. In the "olden days", the only time I ever dealt
with code that used any form of exception handling (setjmp/dojmp), the
exceptions were VERY exceptional. Basically for fatal failures only. We
still used return codes to indicate less-problematic failures, ones that
were benign or could be recovered from.

But .NET uses exceptions for practically any failure. An operation is
assumed to have succeeded, and if it doesn't it throws an exception. This
is just the normal way things work in .NET, and checking for a specific
exception and handling it gracefully is perfectly fine and appropriate.
(As Marc already said, I know ).

Anyway, that's not really all that pertinent...just sharing my own
difficulties in getting used to the .NET paradigm, in case they relate to
your own concerns in any way.

Pete

 

[cbmeeks]

I agree with Marc. IHMO, the reason is *seems* kludgy is probably that
you're used to checking for error return codes and taking appropriate
action based on that. I mean, I don't know what your experience is, but
that's how it is for me. In the "olden days", the only time I ever dealt
with code that used any form of exception handling (setjmp/dojmp), the
exceptions were VERY exceptional. Basically for fatal failures only. We
still used return codes to indicate less-problematic failures, ones that
were benign or could be recovered from.

But .NET uses exceptions for practically any failure. An operation is
assumed to have succeeded, and if it doesn't it throws an exception. This
is just the normal way things work in .NET, and checking for a specific
exception and handling it gracefully is perfectly fine and appropriate.
(As Marc already said, I know ).

Anyway, that's not really all that pertinent...just sharing my own
difficulties in getting used to the .NET paradigm, in case they relate to
your own concerns in any way.

Pete

Thanks for the reply guys.

Now, I have to figure out how to read the entire contents (folders) of
the C:\ drive without it taking 30 seconds on a large drive...lol

cbmeeks

 

[Marc Gravell]

Now, I have to figure out how to read the entire contents (folders) of

the C:\ drive without it taking 30 seconds on a large drive...lol

How about "fdisk" ;-p

Marc

 

[Peter Duniho]

[...]
Now, I have to figure out how to read the entire contents (folders) of
the C:\ drive without it taking 30 seconds on a large drive...lol

You can do that in only 30 seconds? Geez...I wish I had a computer that
fast. Or with so few directories.

Here's a solution for you: do it twice. The second time should be much
faster.