Getting context variables and overriding

Given a context A, on which we have add a layer, called B. We registered a handler C for 'foo:bar' on A and a handler D for 'foo' on B. Handler D only returns data when the first argument is 'baz'. Handler C returns always data, regardless of the arguments
If we request 'foo:bar:baz' from B, in the current implementation, we get NULL as a result. This is however not a desired behavior, because C actually can return data for 'foo:bar:baz'.

After a lengthy discussion with Crell about this, we thought that is would be best to have the implementation follow the instructions described below.
If in the example above, we request 'foo:bar:baz' from B, it should check for handlers in the following order

• foo:bar:baz on B
• foo:bar on B
• foo on B
• foo:bar:baz on A
• foo:bar on A
• foo on A

If a handler is not found, it should check the next in the list. If an handler is registered, but it does not return data, the same thing should happen.

I wrote a patch for this, which is included in this issue.

But, this imposes another question. How should a handler indicate that it does not return data? In the implementation in the patch, it is assumed that if handler returns NULL, it does not return data. But according to Crell that is not a perfectly valid assumption, because in some cases NULL can be a correct value.
There are some ways to solve this. We discussed the first two of them at the codesprint in London.

• If a handler want to return no data, it returns NULL. If the handler really wants to return NULL as data, it should return some specific value. Pro: fairly simple implementation, Con: what should that specific value be, and how can we be sure that there never will be any handler that really wants to return that value for its data.
• If a handler wants to return no data, it should return some specific value. Same Pro's and Con's.
• An approach that we did not discuss in London, which I thought of today: The handler should throw an exception if it does not return data. Pro: really clean implementation and technically perfectly valid; we do not need to make up some artificial value that means 'no data' or 'really really NULL'. Con: some more work, both on the Context side and on the Handler side.

Any thoughts on this?