This pull request is related to the issues underneath: The runtime declares to throw a lot of IOException while it actually isn't, at least in current versions. The problem with those checked exceptions is that they propagate into users code and need to be handled in many different places, which is unnecessary work using try/catch or unnecessary changes for already available method signatures. Without all those exceptions the JavaCompiler can be cleaned up as well a lot and will only keep one of those exceptions where it actually makes sense.
In the integration task I'm currently facing, where I need to replace an old parser with a KS generated one, this makes a huge difference. And we don't even loose anything, because as said, most of those IOExceptions were only declared, not needed at all.
One exception is processZlib which replaced another checked exception with IOException, which make sense of course to not use too many different exception types. But in other places like ensureFixedContents", @GreyCat decided to use a custom class extendingRuntimeException` as well, so I think it's reasonable to use such in this case, too.
I've tried various other implementations in the JavaCompiler to reduce the amount of IOException to the absolute minimum, but nothing is as easy as simply cleaning up the runtime and afterwards cleaning up the compiler.
GreyCat
commented
7 years ago
This pull request is related to the issues underneath: The runtime declares to throw a lot of
IOExceptionwhile it actually isn't, at least in current versions. The problem with those checked exceptions is that they propagate into users code and need to be handled in many different places, which is unnecessary work using try/catch or unnecessary changes for already available method signatures. Without all those exceptions the JavaCompiler can be cleaned up as well a lot and will only keep one of those exceptions where it actually makes sense.In the integration task I'm currently facing, where I need to replace an old parser with a KS generated one, this makes a huge difference. And we don't even loose anything, because as said, most of those
IOExceptionswere only declared, not needed at all.One exception is
processZlibwhich replaced another checked exception withIOException, which make sense of course to not use too many different exception types. But in other places likeensureFixedContents", @GreyCat decided to use a custom class extendingRuntimeException` as well, so I think it's reasonable to use such in this case, too.I've tried various other implementations in the JavaCompiler to reduce the amount of
IOExceptionto the absolute minimum, but nothing is as easy as simply cleaning up the runtime and afterwards cleaning up the compiler.https://github.com/kaitai-io/kaitai_struct_compiler/issues/57 https://github.com/kaitai-io/kaitai_struct_java_runtime/issues/3