[development] Process in code when experiencing an install error in a custom module

[Patrick Dawkins]

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. http://drupal.org/node/911352).

And copying the behaviour of well-established, stable modules, with
caution, is probably a reasonable rule of thumb.



On 7 October 2012 04:25, Darren Oh <darrenoh at sidepotsinternational.com>wrote:

> I hadn’t thought of doing that. Sounds like it should be best practice.
> Thanks for bringing it up.
>
> On Oct 6, 2012, at 8:28 PM, Jeff Greenberg wrote:
>
> > 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?
> >
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20121007/c2652bb5/attachment.html