Directory creation under a restricted folder.
-
My system has a directory C:\AAAA. Where 'AAAA' has security permissions set. ie., only read operations can be performed and no write operations. My application tries to create a directory under 'AAAA'. i.e, C:\AAAA\BBBB. I am trying to handle an exception to avoid a crash - try { Directory.CreateDirectory("C:\\AAAA\\BBBB"); } catch(Exception ex) { } But I am observing that the catch handler is never invoked. My application is trying to create the directory, It is unable to create and it goes to the next statement after the catch block. What would be the code to check whether a directory can be created under AAAA or not.
-
My system has a directory C:\AAAA. Where 'AAAA' has security permissions set. ie., only read operations can be performed and no write operations. My application tries to create a directory under 'AAAA'. i.e, C:\AAAA\BBBB. I am trying to handle an exception to avoid a crash - try { Directory.CreateDirectory("C:\\AAAA\\BBBB"); } catch(Exception ex) { } But I am observing that the catch handler is never invoked. My application is trying to create the directory, It is unable to create and it goes to the next statement after the catch block. What would be the code to check whether a directory can be created under AAAA or not.
Could you use the FileSystemInfo class to get the attributes and check if it's read only?
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis The only valid measurement of code quality: WTFs/minute.
-
My system has a directory C:\AAAA. Where 'AAAA' has security permissions set. ie., only read operations can be performed and no write operations. My application tries to create a directory under 'AAAA'. i.e, C:\AAAA\BBBB. I am trying to handle an exception to avoid a crash - try { Directory.CreateDirectory("C:\\AAAA\\BBBB"); } catch(Exception ex) { } But I am observing that the catch handler is never invoked. My application is trying to create the directory, It is unable to create and it goes to the next statement after the catch block. What would be the code to check whether a directory can be created under AAAA or not.
V K 2 wrote:
and it goes to the next statement after the catch block.
whuch is a clear indication it DID catch the exception; if it hadn't, it would have returned from the current method, until it encountered a matching catch, or it would crash the app. Never have an empty catch block, it makes no sense. All it does is swallow an exception, i.e. hide a problem. :~
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
My system has a directory C:\AAAA. Where 'AAAA' has security permissions set. ie., only read operations can be performed and no write operations. My application tries to create a directory under 'AAAA'. i.e, C:\AAAA\BBBB. I am trying to handle an exception to avoid a crash - try { Directory.CreateDirectory("C:\\AAAA\\BBBB"); } catch(Exception ex) { } But I am observing that the catch handler is never invoked. My application is trying to create the directory, It is unable to create and it goes to the next statement after the catch block. What would be the code to check whether a directory can be created under AAAA or not.
-
My system has a directory C:\AAAA. Where 'AAAA' has security permissions set. ie., only read operations can be performed and no write operations. My application tries to create a directory under 'AAAA'. i.e, C:\AAAA\BBBB. I am trying to handle an exception to avoid a crash - try { Directory.CreateDirectory("C:\\AAAA\\BBBB"); } catch(Exception ex) { } But I am observing that the catch handler is never invoked. My application is trying to create the directory, It is unable to create and it goes to the next statement after the catch block. What would be the code to check whether a directory can be created under AAAA or not.
You are in essence "eating" the exception (if the code above is the actual code you're using). Put a breakpoint on the first bracket and run the code under the debugger. It should stop at the breakpoint.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
V K 2 wrote:
and it goes to the next statement after the catch block.
whuch is a clear indication it DID catch the exception; if it hadn't, it would have returned from the current method, until it encountered a matching catch, or it would crash the app. Never have an empty catch block, it makes no sense. All it does is swallow an exception, i.e. hide a problem. :~
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Luc Pattyn wrote:
Never have an empty catch block, it makes no sense. All it does is swallow an exception, i.e. hide a problem. Unsure
AMEN, BROTHER!!!!!
I wasn't, now I am, then I won't be anymore.
-
My system has a directory C:\AAAA. Where 'AAAA' has security permissions set. ie., only read operations can be performed and no write operations. My application tries to create a directory under 'AAAA'. i.e, C:\AAAA\BBBB. I am trying to handle an exception to avoid a crash - try { Directory.CreateDirectory("C:\\AAAA\\BBBB"); } catch(Exception ex) { } But I am observing that the catch handler is never invoked. My application is trying to create the directory, It is unable to create and it goes to the next statement after the catch block. What would be the code to check whether a directory can be created under AAAA or not.
Is it really an empty catch block or you removed the code inside it for the post? Never ever have an empty catch block. Also, never use try/catch/finally as if they are same as if/else. I, personally, would prefer checking for the permission and then deciding the flow.