I’m developing a couple of custom Gradle Tasks which do several kinds of operations that can failure for multiple reasons.
For instance, reach a server that returns a non-200 response; failed I/O, failed command execution etc…
These are all business-specific issues which I need to propagate to the user.
So far, I’m catching (or interpreting) any of those issues that happen within my Gradle Tasks and simply throwing a GradleException with a corresponding error message.
Question: Is it the correct way of handling errors after all? Or should the GradleException be reserved for Gradle-specific issues, and not be used at all for business-specific ones at all?
One problem I’m having with that approach is that the CI Tools (GitHub, Jenkins) sometimes need to react according to the issue.
For example, I have a task that runs a certain command. This command returns an exit code 5 for, let’s say, wrong input, and 6 for unreachable server, in which case I want my CI Tool to wait and retry.
Since I’m propagating every error as a GradleExpection(message), I would need to parse that message again even though the exit code was available in the Gradle runtime…