Unique exception for input step abort

Details

Description

When using input in conjunction with milestone it is impossible to detect the difference between the user choosing to "abort" (e.g. say "no" to the prompt) and the build being abandoned because it was superseded. Both cases throw FlowInterruptedException

This makes it impossible to take meaningful actions upon the user choosing to abort that you would not want to take if the input goes un-answered.

One possible solution would be for the input-invoked Abort to throw a unique exception type which extends FlowInterruptedException.

Jesse Glick
added a comment - 2017-04-24 15:49 You can already check for org.jenkinsci.plugins.workflow.support.steps.input.Rejection as one of the causes but this is not @Whitelisted or otherwise convenient.

So we can't switch to a different exception here - too many places expect/handle FlowInterruptedException for all abort cases, including input, and FlowInterruptedException is a final class, so we can't extend it. As Jesse mentioned, looking for Rejection in the causes is the best approach - I'll get a PR up to whitelist FlowInterruptedException#getCauses() and post an example here once it's up.

Andrew Bayer
added a comment - 2018-01-12 14:30 So we can't switch to a different exception here - too many places expect/handle FlowInterruptedException for all abort cases, including input , and FlowInterruptedException is a final class, so we can't extend it. As Jesse mentioned, looking for Rejection in the causes is the best approach - I'll get a PR up to whitelist FlowInterruptedException#getCauses() and post an example here once it's up.

Implemented suggestions from here and other issue(s) related to challenges accurately detecting abort conditions that works reasonably well and covers detection of input rejection. Details posted here, if it is useful to anybody else:

Chris Russell
added a comment - 2018-08-17 16:44 Implemented suggestions from here and other issue(s) related to challenges accurately detecting abort conditions that works reasonably well and covers detection of input rejection. Details posted here, if it is useful to anybody else:
https://issues.jenkins-ci.org/browse/JENKINS-28822?focusedCommentId=346492&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-346492

James Hogarth
added a comment - 2018-08-22 11:50 Andrew Bayer "Lemme think on JENKINS-41272 and leave this sitting here for the moment."
Have you thought about this? I've got a developer who wants to access the causes for an abort but of course getCauses() on FlowInteruptedException isn't whitelisted yet by default...