0

I have a file that I want to create, so I want to ensure that all of its parent directories are in place before it is created (or I will get an error).

File fileA = fileB.getParentFile();

Now, if fileB does in fact have a parent file, fileA will contain an actual file object. However, if fileB does not have a parent, fileA will be equal to null, and calling createNewFile() on fileA will result in a NullPointerException error. Thus, the only way to create fileA safely would be to then do the following:

if (fileA != null) {
    fileA.mkdirs();
{
fileB.createNewFile();

However, the general consensus seems to be that you should never use the != null check in your code because it is poor practice. Are there exceptions to this rule, and is this one of them? Or is there a better way I could phrase this code?

Adrian M
  • 751
  • 2
  • 10
  • 24
  • 1
    Try to this way `File fileA = fileB.getAbsoluteFile().getParentFile();` – Skizo-ozᴉʞS ツ Jul 26 '15 at 17:55
  • 1
    Using `!= null` is definitely not always poor practice, and completely fine here. As `java.io.File.getParentFile()`'s documentation confirms, a null return value does not indicate exceptional behaviour for that specific method. – Emile Pels Jul 26 '15 at 17:57
  • `First rule of coding is there is no fixed rule` , when you have to use `!=null` like this situation, you should use. – Karthik Jul 26 '15 at 18:01
  • You could Guavas [`Files.createParentDirs(File)`](http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/Files.html#createParentDirs%28java.io.File%29) method to create parent directories for you. So you don't have to bother about it. – Tom Jul 26 '15 at 18:04

2 Answers2

2

Generally, there's nothing wrong with returning null in case when method design implies that requested object may be non-existing at the time of method's invokation (as in your example with fileB.getParentFile(); where fileB could legally have no parent).

Also, it's fine to throw and properly handle NPE in some situations according to all java-devs bible -- Effective Java, 2nd Edition by Joshua Bloch - Item 60: "If a caller passes null in some parameter for which null values are prohibited, convention dictates that NullPointerException be thrown rather than IllegalArgumentException."

One more option to avoid null-checks is Null Object Pattern usage. Don't return a null if you can help it, seriously. In case with collections, for example, returning Collections.emptyMap() (or any other empty collection) is considered a good practice instead of returning null.

For more info about avoiding-null practice you could check something like this article. Feel free to ask if my explanation seems too vague.

solar
  • 1,344
  • 1
  • 8
  • 14
-1

A better way is to check with exists() if a direcotry or file exist already:

File fileA = new File(fileB.getParentFile());

if (!fileA.exists()) {
  fileA.mkdirs();
} else { 
  fileB.createNewFile(); 
}

See api for more infos: File

JoGe
  • 872
  • 10
  • 26
  • is it okay to pass `null` to `File` constructor? – Karthik Jul 26 '15 at 18:06
  • @prakharsingh95 No it won't. It won't even compile. – Tom Jul 26 '15 at 18:08
  • @Tom Why? seems compile worthy. I can't spot it :-(. – xyz Jul 26 '15 at 18:10
  • @prakharsingh95 If you can't spot it, then feed your IDE with that snippet ;P. – Tom Jul 26 '15 at 18:11
  • Sorry.. my fault: `new File(fileB.getParentFile().getAbsolutePath());` and the `createNewFile()` throws a IOException but I think Adrian M handle his code in a try-catch or throw it to parent. – JoGe Jul 26 '15 at 18:21
  • 2
    The whole point is that fileB.getParentFile() is null. You can't call exists(), mkdirs(), or getAbsolutePath() on a null. – charles-allen Aug 09 '17 at 13:08