> You want, on top of everything else, the computer to refuse to run your program at all, unless you explicitly handle every possible edge case?
Precisely!
Even better - let the IDE suggest to you all of the possible exceptions and when you're feeling lazy or are hacking away at a prototype, either let it add a "throws SomeException" to the method signature and make it someone else's problem up the call chain, or just add a catch all after you've handled the ones that you did want to handle!
After all, none of us can recall the hundreds of ways network calls can get screwed up, but we're pretty sure what to do at least in a subset of those, but we'd also forget about those without these reminders. Not only that, but when you're writing financial code or running your own SaaS, you'll at the very least will want your error handling code to be as bulletproof as the guarantees offered to you by your language's rigid type systems.
Then, when you've finished hacking together your logic, your instance of SonarQube or another tool could just tell you: "Hey, there are 43 places in your code where you have used logic to catch multiple exceptions" and then you could review those to decide whether further work is necessary, or whether you can add a linter ignore comment to the code explaining why you don't want to handle the edge cases, or just do so in the static code analysis tool, so all of your team members know what's up.
Alternatively, if you're just writing something for yourself, just leave it as it is, knowing that if you'll ever need to publish your code for thousands of others to use, then you probably should go back to those now very visible places and review it.
So essentially:
/**
* Attempts to load a Sprite from a file. You can then use the instance to display it on screen.
* @param file This is the file that we want to load the image from. Use relative path to "res" directory.
* Our engine loads PNG files and technically can also load GIF files because someone hacked that functionality together in an evening.
* That's kind of slow though, so we should use PNGs whenever possible. See ENGINE-33452 for more details.
* @return A Sprite instance that you can pass to the rendering logic to put it on the screen, or alternatively process the loaded image in memory.
*/
public Sprite loadSprite(@NotNull File file) throws SpriteGenericException, FileSystemGenericException {
try {
return FileSystemSpriteLoader.loadPNG(file);
} catch (ImageWrongFormatException e) {
wrongImageFormatLogger.warn("We found a " + e.getActualFormat() + " format file: " + file.getPath(), e); // the art team should have a look at this
if (e.getActualFormat().equals(ImageFormats.GIF)) {
return FileSystemSpriteLoader.loadGIF(file); // TODO unoptimized call because we needed GIFs for ENGINE-33452, remove later
} else {
throw SpriteGenericException("We failed to load sprite from file: " + file.getPath() + " because of wrong format: " + e.getActualFormat(), e);
}
} catch (SpriteCorruptedException e) {
brokenImageLogger.warn("We found a corrupted sprite in file: " + file.getPath(), e); // maybe the pipeline is broken again?
throw SpriteGenericException("We failed to load sprite from file: " + file.getPath() + " because of image corruption", e);
} catch (Exception e) { // TODO ENGINE-44551 handle the file system access cases later once the API is stable and we know how it'll work on Android
throw FileSystemGenericException("We failed to load sprite from file: " + file.getPath(), e);
}
}
I prefer software blowing up in predictable ways as opposed to doing so unexpectedly. Even Java is vaguely close to being what i'm looking for, however unchecked exceptions simply isn't acceptable from where i stand.