This absolutely perplexes me. One of those weird things in java.
Could anyone explain why the java designers designed mkdir() not to throw an IOException? For me it seems like the mkdir() is an operation similar to createNewFile() (the only difference is that you are creating a new directory instead of a new file).
But whereas createNewFile() has been designed to throw an IOException, mkdir() isn't. This sounds like a flawed design to me. How come mkdir() has been designed this way? Look at my code below that I have INTENTIONALLy created to FAIL, since I am trying to make the directory tmp1/tmp2 i.e. two level of directories (in a Linux platform) and it can't be made since tmp1 doesn't exist to start with. But even though this mkdir() fails to create the directories, it fails SILENTLY, without a single exception or error being thrown. This is absolutely unacceptable and unreliable to me. How can anyone depend on this kind of a behavior of mkdir() ?
So for me it seems to make total logical sense that mkdir() should have been designed to throw an IOException if it fails to make the directory that the user needs. It beats me why it hasn't been designed this way. WHY? Please don't tell me that that is how the JLS was designed/written. That is not an acceptable explanation/answer.
Asking us to speculate on why a group of people did or didn't do something fifteen years ago is generally a fruitless exercise. All you will actually get, if anything, is a bunch of other people's opinions about what they might have done in the same situation.
As for the "unreliable" part... the method returns true if the directory was created, false if not. What's unreliable about that? If you ignore the return value then you can certainly write an unreliable program, but that would be your fault and not the fault of the people who designed the method.
Right, I absolutely agree. Although I like to depend on the return values from the mkdir() method, I can understand the developers who are accustomed to depending on Checked Exceptions to guide their coding. Anyway, with respect to Larry's code snippet, if additional code tries to write to the nonexisting tmp1/tmp2 directory then we would be dutifully informed by the IOException and that's not so bad.
My guess is that the creator of the mkdir method wanted something that will work on all platforms. Since the mkdir method calls a native method, I'm guessing that it was easier to simply pass on the boolean value returned from the JNI code.
By the way - you are wrong in your assumption about how the createNewFile method works: it also returns true or false depending on whether the file was created or not. createNewFile only throws an IOException if there was an I/O error.
I was thinking in terms of instantiating FileWriter and PrintWriter. They don't return true or false when being instantiated.
Joined: Feb 03, 2009
Thanks for all the inputs. I totally overlooked the fact that the mkdir() does return a true or false value depending on if it succeeded or not.
I guess the proper question would have been "Is the mkdir() method immune to IOException unlike the createNewFile() method"? Say for example, it would have been nice if the mkdir() method threw an exception indicating the reason why it failed, say one of the following reasons:
1) mkdir() failed because no space was left on the device
2) mkdir() failed because the user didn't have the permission to create the new directory
3) mkdir() failed because the directory already exists
4) ....and othe reasons...assuming mostly beyond user's control...
I do understand the fact that mkdir() DOES return a true or false depending on if it succeeded. But it would have been more value addition if the user was given a specific reason (by throwing an exception indicating one of the reasons above or other reasons) on why the mkdir() operation failed (in addition to returning false). That way the exception would clearly indicate why the mkdir() failed. This will avoid any need for the user to speculate on his part on trying to guess why mkdir() might have failed and help the user to take the proper corrective action.
But since no exceptions are being thrown and the user has to rely on only the true or false value returned, now the user would have to resort to speculation on why the mkdir() failed. May be that is what I call as the "unreliable" part. Does my reasoning make sense?
Again it isn't my intention to argue or asking others to speculate, but to have a healthy discussion.