We are using a declarative Jenkins pipeline in our project that needs to react to build failures (e.g. send Slack notifications...). Basically it looks like this:

pipeline {
   stages {
      stage("one"){
        steps {
          sh "./stepOne"
          sh "./stepTwo"
          sh "./stepThree"
        }
        post {
          success {
            // ... stage one success handler...
          }
          failure {
            // ... stage one failure handler...
          }
        }
      }
      // more stages here...
   }
   post {
     success {
       // ... build success handler...
     }
     failure {
       // ... build failure handler...
     }
   }
}

Now, let's assume that the command sh "./stepTwo" fails to execute for some reason. It can return with exit code -1, the shell might crash, or any other abnormal condition might occur. Here is what I would assume to happen:

1) sh "./stepThree" (and the remainder of stage "one") is skipped
2) stage one failure handler is executed
3) build failure handler is executed
4) build is terminated and marked as failing, with stage "one" as the "root cause".

Here is actually happens:

1) Jenkins detects that sh "./stepTwo" has terminated abnormally.
2) The entire build is marked as failure and is terminated immediately. No post handlers are executed.

The issue here is that I would expect post handlers to always be executed, even when the build fails at some stage. They need to have "try-finally" semantics in my opinion, otherwise a post failure clause is not very useful.

My current workaround is to use catchError clauses, but those are suboptimal as they require me to mark the build as "failure" myself. Futhermore, they are just noise in this case, as I only want to execute my post handlers before the build is terminated.