I work on a project with a legacy service layer that returns null in many places if a requested record does not exist, or cannot be accessed due to the caller not being auth
Unchecked exceptions help avoid code clutter. For example consider this code
try
{
File file = new File("file");
FileReader fileReader = new FileReader(file);
BufferedReader bufferedReader = new BufferedReader(fileReader);
String temp = "";
StringBuilder result = new StringBuilder("");
while ((temp = bufferedReader.readLine()) != null)
{
result.append(temp);
}
System.out.println(result);
}
catch (FileNotFoundException e)
{
e.printStackTrace();
}
catch (IOException e)
{
e.printStackTrace();
}
We handle two exception types, but if there is no actionable event that can occur by handling these exceptions, why catch them in the first place ? The answer is not to throw the checked exceptions, since eventually some class up the call hierarchy will have to handle it (Or it gets thrown to the JVM). If the developer is really interested in handling these, the catch the specific RuntimeException class that addresses the problem.
Catch blocks that hold multiple exceptions go some way in reducing this clutter