add better error message when network lock is held

[mitchellwrosen]

This PR adds a better error message when attempting to acquire the network lock while it is held.

I think this partially addresses #190, though we could/should also add documentation to execute to call out this behavior.

To do:

• Decide on an exception type. This currently uses fail in IO, so IOException. I find this kind of nasty and old-school, but this exception shouldn't really ever be caught and handled in any particular way.
• Nail down exact wording of error message
• Update execute documentation (and are there other common ways this can occur?)

[mitchellwrosen]

Any suggestions for the exception type or what the error message should say?

[HeinrichApfelmus]

Decide on an exception type. This currently uses fail in IO, so IOException. I find this kind of nasty and old-school, but this exception shouldn't really ever be caught and handled in any particular way.

The standard style in the Control.Exception module is to define a single type for each exceptional outcome. Here is what I would suggest:

-- | Thrown when an event handler is fired from within a `Network`
-- while handling events. This usage does not have well-defined semantics.
--
-- Typically, this happens when `fire` is called during `execute`.
-- You may want to use `reactimate` instead of `execute`.
--
-- If really want to `fire` an event from within `execute`,
-- you need to add a delay;
-- `liftIOLater` can be helpful in this situation.
--
-- Example: […]
data NestedEventHandling = NestedEventHandling

instance Exception NestedEventHandling

Nail down exact wording of error message

I would take a subset of the comment documenting the NestedEventHandling exception and simply refer to the exception.

Update execute documentation (and are there other common ways this can occur?)

👍 Referring to the documentation of the exception is probably the right way to go. I don't think that there is any other way — reactimate can use fire, if I remember correctly.