Moderate Code Cleanup

[ethauvin]

Matches RIFE2 rules, should be easier to review.

[gbevin]

This also needs to be added in the resolveRepository method

[ethauvin]

This also needs to be added in the resolveRepository method.

Wasn't caught when GOOGLE was added either. Fixed now.

[gbevin]

I'm still not on board with having a full stack trace here reported to the user, adding an IOException makes things even worse..

I don't disagree with reporting to the user, via logging. As far as reporting to a developer, the current state of rife2 exceptions is very generic. It make it really hard to track problems without a full stacktrace. You probably don't see it as a problem, because it is your code and you're very familiar with it, but for me, it's a pain in the butt.

[ethauvin]

I'm still not on board with having a full stack trace here reported to the user, adding an IOException makes things even worse.

Having the cause message added to the exception message makes it virtually impossible to process programmatically. If you want it to be humanly readable, it should be logged.

[gbevin]

I'm still not on board with having a full stack trace here reported to the user, adding an IOException makes things even worse.

Having the cause message added to the exception message makes it virtually impossible to process programmatically. If you want it to be humanly readable, it should be logged.

SignException can be caught for programmatic processing, there's nothing that can be gained from the InterruptedException nor the artificially added IOException

[ethauvin]

I'm still not on board with having a full stack trace here reported to the user, adding an IOException makes things even worse.

Having the cause message added to the exception message makes it virtually impossible to process programmatically. If you want it to be humanly readable, it should be logged.

SignException can be caught for programmatic processing, there's nothing that can be gained from the InterruptedException nor the artificially added IOException

If the cause message is added to the original message, it cannot reliably be processed. The IOException is hardly artificial ; the process stream error is an IO error.

[gbevin]

If the cause message is added to the original message, it cannot reliably be processed. The IOException is hardly artificial ; the process stream error is an IO error.

That is not an IO error, that is the std error output from the cmd line process doing the signing, it's very much not a Java IOException, it's just a message from the executable.

[ethauvin]

If the cause message is added to the original message, it cannot reliably be processed. The IOException is hardly artificial ; the process stream error is an IO error.

That is not an IO error, that is the std error output from the cmd line process doing the signing, it's very much not a Java IOException, it's just a message from the executable.

As far as Java is concerned, a stderr message is an IO error, don't think there's much to argue about there.

[gbevin]

As far as Java is concerned, a stderr message is an IO error, don't think there's much to argue about there.

I don't agree, where does Java say that any message written to stderr should be treated as an IO error? The reason for the message on stderr could be anything, and very likely not IO related.

[ethauvin]

As far as Java is concerned, a stderr message is an IO error, don't think there's much to argue about there.

I don't agree, where does Java say that any message written to stderr should be treated as an IO error? The reason for the message on stderr could be anything, and very likely not IO related.

stderr, etc. are java.io.printStream. You are only throwing the IO error that you received from the process. Then you are qualifying it by also providing the actual error message that was returned by the process. I would personally qualify it using something like gpg returned the following error: xxx.

[gbevin]

As far as Java is concerned, a stderr message is an IO error, don't think there's much to argue about there.

I don't agree, where does Java say that any message written to stderr should be treated as an IO error? The reason for the message on stderr could be anything, and very likely not IO related.

stderr, etc. are java.io.printStream. You are only throwing the IO error that you received from the process. Then you are qualifying it by also providing the actual error that was returned by the process. I would personally qualify it using something like gpg returned the following error: xxx.

Of course streams are IO, doesn't mean that the message printed on stderr by the process is IO related. If there would be an error reading from the stream, that would be an IOException, reading the text, is not.

[ethauvin]

Of course streams are IO, doesn't mean that the message printed on stderr by the process is IO related. If there would be an error reading from the stream, that would be an IOException, reading the text, is not.

Hmm. I posted a reply a while back. I wonder where it went. Anyway, I reverted the changes. There are many instances of rife2/bld reporting incomplete stacktrace. In this case, it should first report receiving an error when executing the process, then the error message that was received, not trying to magically combine the two.