Use optionals for return values that may be null to enforce a client check

[gok99]

What feature(s) would you like to see in RepoSense

A large number of getter functions have optional return semantics - the return value might be null if the field is uninitialized or not applicable. The problem is often that it's hard to know if a check is necessary without having the client know about the underlying details of the initialization logic.

RepoSense/src/main/java/reposense/model/ConfigRunConfiguration.java

Lines 44 to 67 in bbb2f69

	Path authorConfigFilePath = cliArguments.getAuthorConfigFilePath();
	Path groupConfigFilePath = cliArguments.getGroupConfigFilePath();
	if (authorConfigFilePath != null && Files.exists(authorConfigFilePath)) {
	try {
	authorConfigs = new AuthorConfigCsvParser(cliArguments.getAuthorConfigFilePath()).parse();
	RepoConfiguration.merge(repoConfigs, authorConfigs);
	RepoConfiguration.setHasAuthorConfigFileToRepoConfigs(repoConfigs, true);
	} catch (IOException | InvalidCsvException e) {
	// for all IO and invalid csv exceptions, log the error and continue
	logger.log(Level.WARNING, e.getMessage(), e);
	}
	}
	if (groupConfigFilePath != null && Files.exists(groupConfigFilePath)) {
	try {
	groupConfigs = new GroupConfigCsvParser(cliArguments.getGroupConfigFilePath()).parse();
	RepoConfiguration.setGroupConfigsToRepos(repoConfigs, groupConfigs);
	} catch (IOException | InvalidCsvException e) {
	// for all IO and invalid csv exceptions, log the error and continue
	logger.log(Level.WARNING, e.getMessage(), e);
	}
	}

Not all nulls necessarily bad however. In some cases like this:

RepoSense/src/main/java/reposense/model/AuthorConfiguration.java

Lines 165 to 178 in bbb2f69

	public void removeIgnoredAuthors(List<String> ignoredAuthorsList) {
	for (String author : ignoredAuthorsList) {
	Author authorToRemove = null;
	if (authorEmailsToAuthorMap.containsKey(author)) {
	authorToRemove = authorEmailsToAuthorMap.get(author);
	} else if (authorNamesToAuthorMap.containsKey(author.toLowerCase())) {
	authorToRemove = authorNamesToAuthorMap.get(author.toLowerCase());
	}
	if (authorToRemove != null) {
	removeAuthorInformation(authorToRemove);
	}
	}
	}

the scope of the nulls are only within a function, which does not suffer from the same issue of having to reason about the presence of a value.

Java Optionals are a good way to deal with this pattern, by enforcing a client check when a return value may not be present. This has both the effects of minimizing programmer error and helping document the intended nature of function return values. Ideally, return values that are not Optional are guaranteed to be present.

While this problem is not limited to getter functions, this would be a good place to start this refactor, and consider other instances on a case-by-case basis.