I'm not sure about that; I don't really see what problem it would solve. An install error might be caused by a bug in the contrib module, in which case the module's broken (so this becomes moot), or it might be caused somewhere in the Drupal core API (not the responsibility of contrib), or some problem in the host system, in which case it's the host's problem. If code fails it should fail hard, right? If you're trying to work around failures of Drupal core, then patch core instead. There are some core issues around data integrity (e.g. <a href="http://drupal.org/node/911352">http://drupal.org/node/911352</a>).<div>
<br></div><div>And copying the behaviour of well-established, stable modules, with caution, is probably a reasonable rule of thumb.<div><div><div><br><br><br><div class="gmail_quote">On 7 October 2012 04:25, Darren Oh <span dir="ltr"><<a href="mailto:darrenoh@sidepotsinternational.com" target="_blank">darrenoh@sidepotsinternational.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I hadn’t thought of doing that. Sounds like it should be best practice. Thanks for bringing it up.<br>
<div class="HOEnZb"><div class="h5"><br>
On Oct 6, 2012, at 8:28 PM, Jeff Greenberg wrote:<br>
<br>
> I'm curious what others are building into their module install process in the event of an error partway through. For example, if your install script creates one or more bundles, fields and field instances, if an error occurs at some point during that process, do you handle it all like a transaction and back out what you have created to that point?<br>
><br>
> My instinct would be to do that, though I realize it can get complicated, such as the event where some of the fields that were to be created earlier on in the process already existed, etc. I'm asking, though, because of the several modules I've looked at so far, none seem to be doing this.<br>
</div></div></blockquote></div><br></div></div></div></div>