Notice: Undefined index: tid in views_handler_field_term_node_tid->add_self_tokens()

I tested both patches (local):

Let's see, in the case that the array is empty the !empty works but there are other cases where the array is not empty but it DOES NOT cotains the indexes defined for that specific Field and get_render_tokens it's still called on that Field (Field handler).
Mmm, ...diferent test cases (with data in the UI "rewrite results" & without) and still there.

Ok, a lot of testing, specially verifing that the items ($item) are going to be called on the wright handler class.
Also think it's OK !empty, in principle if the item is not empty is the handler's responsability to handle it in a proper way (that's why is called handler ;-)
Patch views-1130760-3.patch solve this one.
As a curiosity: the bug can be seen online (someone forgot to turn off the error reporting in a productive env. or forgot the "use at your own risk" thing ;-)
http://reliefweb.int/node/396320

Views is basicaly a query constructor + formating, so in this picture the roll of the fields is to add elements to the SELECT clause of the query (roughly speaking) and limiting this situation doesn't sound like a promising solution.

Check in the tokens

What does that mean exactly?

I see the error of #11 but although they are the same (as the original) conceptually they aren't:

Also think it's OK !empty, in principle if the item is not empty is the handler's responsability to handle it in a proper way (that's why is called handler

still applys.

sorry :-(

Ok, let's try to close this one.
...but first things first:
with the current dev i can not reproduce the issue any more, and it makes sense becouse following the logic in the handlers i can see what is happening:
At one point views_handler_field::advanced_render is called, then $raw_items are collected by views_handler_field_prerender_list::get_items as an array of items containig all the info needed by views_handler_field_term_node_tid::add_self_tokens (also the index tid), then comes the loop in views_handler_field::advanced_render

foreach ($raw_items as $count => $item) {
          $value = $this->render_item($count, $item);
          if (is_array($value)) {
            $value = drupal_render($value);
          }
          $this->last_render = $value;
          $this->original_value = $this->last_render;
dpm($item);
          $alter = $item + $this->options['alter'];
          $items[] = $this->render_text($alter);
        }

as it can be seen (and checked e.g. with dpm()) $alter = $item + $this->options['alter'], contains enough info when it's passed in views_handler_field::render_text to views_handler_field::get_rendered_tokens() and subsequently to views_handler_field_term_node_tid::add_self_tokens, so as far as i see it, it SHOULD be working OK.
@rlmumford now, are you using the lastest dev?? Would you post an export???

@mcarbone yes, you're right ;-)
The problem is that if the entity (node) in the result doesn't have any taxonomy term then $raw_items is empty, therefore views_handler_field::render_text is called only with the handler options i.e. $this->render_text($this->options['alter'] and eventually views_handler_field_term_node_tid::views_handler_field_term_node_tid() without the necesary info becouse this node doesn't have a taxonomy term. So there are different levels in wich this check (or other logic e.g. reimplementig get_items()) can be made, my opinion: since "everything" works for other handlers we should take care of it in views_handler_field_term_node_tid itself, but this is arguable. I'm also defining the token even when the entity has no term assigned, it's a less agressive approach.

@mcarbone Tanks for the review
Here another one with a litter code reduction technique.