wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Why mkdir() was designed not to throw an IOException? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Why mkdir() was designed not to throw an IOException?" Watch "Why mkdir() was designed not to throw an IOException?" New topic

Why mkdir() was designed not to throw an IOException?

Larry Olson
Ranch Hand

Joined: Feb 03, 2009
Posts: 142
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.
Paul Clapham

Joined: Oct 14, 2005
Posts: 18541

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.
Larry Chung
Ranch Hand

Joined: Feb 02, 2010
Posts: 247
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.

Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404

As Paul states, all we can do is speculate.

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.

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Larry Chung
Ranch Hand

Joined: Feb 02, 2010
Posts: 247
createNewFile method???

I was thinking in terms of instantiating FileWriter and PrintWriter. They don't return true or false when being instantiated.
Larry Olson
Ranch Hand

Joined: Feb 03, 2009
Posts: 142
Hey guys,

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.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
subject: Why mkdir() was designed not to throw an IOException?
Similar Threads
renameTo method in io package...
catch block does not compile
File's mkdir() method does not throw an exception?
Javacaps-mock Q
doubt in files and Directories