Bad zip errors are hard to debug

[ChiefArug]

Currently when you attempt to run the installer on a corrupt zip you get an output such as

Exception in thread "main" java.util.zip.ZipError: zip END header not found
	at com.sun.nio.zipfs.ZipFileSystem.zerror(ZipFileSystem.java:1661)
	at com.sun.nio.zipfs.ZipFileSystem.findEND(ZipFileSystem.java:1040)
	at com.sun.nio.zipfs.ZipFileSystem.initCEN(ZipFileSystem.java:1049)
	at com.sun.nio.zipfs.ZipFileSystem.<init>(ZipFileSystem.java:130)
	at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:139)
	at java.nio.file.FileSystems.newFileSystem(FileSystems.java:390)
	at net.neoforged.cliutils.JarUtils.getFileCountInZip(JarUtils.java:15)
	at net.neoforged.jarsplitter.ConsoleTool.main(ConsoleTool.java:96)

(this particular output is from running jar splitter from the console with a corrupt Minecraft jar (.minecraft/versions/1.21/1.21.jar) passed in)

This error and stacktrace is slightly helpful at figuring out what is wrong, until I go look at that class and see there are four possible files that it could be throwing on. And for the average user that has no idea what zip END header not found means (the zip is bad, most likely corrupt), or how to read code so it is of no help to them.
A similar situation can happen in other places in the code, where zips are just opened and assumed to be good, causing annoying to debug errors when they are not.
Examples of this happening, from the NeoForge discord: 1 2.

I see two potential solutions could to fix this.

1. Each opening gets wrapped in a try catch so that a more informative error (including the file name!) can be thrown.
2. Each file name is logged before it gets opened, so that when reading the logs/terminal output one can see which file was last attempted to be opened. This is the worse solution as it increases log spam.