Now it is ;)

Excellent! Is this documented?

The AbsoluteReport in the lab package now flags all unexplained errors (also 
invalid solutions) in a separate table. Additionally, warnings are raised already 
when the results are fetched from the experiment directory. I'll close this 
issue, feel free to reopen in case something's missing.

Note from issue197: Flag invalid plans too.

> MemoryErrors and timeouts are caught better now, but are not added to the
> properties file since they are expected errors. Is that the desired
> behaviour?

Errors in the translator or preprocessor should always be considered errors (if
nothing else, they are serious performance issues). For the search code, running
out of memory or time should indeed be considered an expected failure.

I have looked into this and implemented this functionality in the run-template.
Errors are now added to the properties file for each of the three parts 
(pre/post-processing, main command), so segmentation faults or missing inputs 
can be seen in the reports. MemoryErrors and timeouts are caught better now, but 
are not added to the properties file since they are expected errors. Is that the 
desired behaviour? 
Errors in the translator cause the preprocessor not to be run now.

Although the errors are present in the reports, we should probably think about a 
better way to present them. At the moment they are just another table.

Quoting Malte in issue131:

Regarding error messages, I wonder what our current status is regarding expected
vs. unexpected failures of the planner. "Expected failures" are when the planner
fails to solve a problems because it times our or runs out of memory;
"unexpected failures" are everything else (segmentation faults, missing inputs,
bugs in the scripts that call the planner).

Unexpected failures should always be flagged so that they're not overlooked when
analyzing experimental results.