Var schema in tMap receives even non-matching rows in an inner join

[Anonymous]

Just come across this behaviour - borne out by the code that gets generated - and am a) wondering why this has been implemented like this and b) hoping it might save others time...
If you have an inner join on the left hand side of your tMap and try to use the Var table as a means of constructing expressions to use on the output(s), it seems that even rows from the input stream that do not meet the inner join are processed in the Var section of code and need to have null checks placed around any expressions to avoid possible null pointer exception issues. The output schema(s) do not receive the non-matching rows. We have typically - perhaps unwisely - used the Var table to make it clearer when viewing a flow, exactly which column values get overridden in the processing.
Assuming this implementation is by design, why?
M

[Anonymous]

Hi,
The screenshot of tMap setting does not display the whole expression. Could you please show us your whole expression in Var? Does it work well when you use expression  on the right hand side of your tMap(output) without using Var?  
What's the build version you are using?
Best regards
Sabrina

[vapukov]

Sabrina - it is fact, when You have formulas in tMap Var section - this values not rejected  and calculated for each row
If same formula put in right side, all will be ok

Think it is not error, but just logic
because we can use Var section for many reasons, for example for:
[list=*]

use it in rejected output

for auto-increment, row count (and in this case - it good not skip nulls)

etc