# Question on where best to implement a "--verify-failure" feature.

**URL:** <https://forum.ansible.com/t/question-on-where-best-to-implement-a-verify-failure-feature/16482>\
**Category:** Ansible Developer\
**Created:** [October 9, 2014, 11:39pm UTC](https://forum.ansible.com/t/question-on-where-best-to-implement-a-verify-failure-feature/16482 "2014-10-09T23:39:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![maxamillion](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/maxamillion/32/98_2.png) [@maxamillion](https://forum.ansible.com/u/maxamillion)\
**Post date:** [October 9, 2014, 11:39pm UTC](https://forum.ansible.com/t/question-on-where-best-to-implement-a-verify-failure-feature/16482/1 "2014-10-09T23:39:19Z")

</div>

Hello all,  
&nbsp;&nbsp;&nbsp;&nbsp;I am currently poking my way through the core Ansible code trying  
to figure out how best to implement a "--verify-failure" feature, what  
I mean by that is there would be an option to run playbooks  
interactively such that in the event a failure happened you were  
presented with a set of options on how you wanted to handle that. I've  
mocked up some output on what it would look like (note: I'm by no  
stretch married to the arg name of "--verify-failure" but that's my  
working title).

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ansible-playbook myplaybook.yml -i inventory.txt -u root --verify-failure  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PLAY [all]

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\
**Post date:** [October 13, 2014, 8:44pm UTC](https://forum.ansible.com/t/question-on-where-best-to-implement-a-verify-failure-feature/16482/2 "2014-10-13T20:44:01Z")

</div>

A few random thoughts:

(A) the “blocks” thing we want to do (try/except/etc) gets very close to the error handling capabilities you want above

(B) we need to do some refactoring to get to the point where A is attainable, and that’s started recently

(C) I’m not sure about going interactive and what that means for things calling Ansible from Jenkins, as well as for things like Tower.

I think we should probably discourage interactivity and instead have the block specify what to do on error.

I would definitely discourage running things against the Runner API as we’ve more recently decided it’s not going to be stable, it mainly exists to serve to power /usr/bin/ansible-\*, while we are committed to maintaining module and plugin level compatibility, the Runner() API is going to be going through some major changes.