Originally the delete() method did not throw errors because runCommand() did not return anything sensible as far as errors were concerned (it would throw errors if no state was found, which doesn't really impact the result of the delete, because the resource is being deleted anyways). Now that runCommand() throws errors only when the scripts returns a non zero error condition, it makes sense for delete() to throw that error, like create(), update(), and read() do. Yes, this could cause an awkward condition where you have an error in the delete() script and cannot update it because the delete() keeps failing, but that is a small inconvenience. Generally, users will want to know if a script is returning non-zero error condition and if this means the resource must be manually removed from the state file to proceed, that is an acceptable outcome.
Closes issue #40
Originally the
delete()
method did not throw errors becauserunCommand()
did not return anything sensible as far as errors were concerned (it would throw errors if no state was found, which doesn't really impact the result of the delete, because the resource is being deleted anyways). Now thatrunCommand()
throws errors only when the scripts returns a non zero error condition, it makes sense fordelete()
to throw that error, likecreate()
,update()
, andread()
do. Yes, this could cause an awkward condition where you have an error in thedelete()
script and cannot update it because thedelete()
keeps failing, but that is a small inconvenience. Generally, users will want to know if a script is returning non-zero error condition and if this means the resource must be manually removed from the state file to proceed, that is an acceptable outcome.For the following resource:
The following error will be thrown: