Stored-error functionality & error cells

[GoogleCodeExporter]

If a date value cannot be parsed properly within the data, e.g. when 
transforming a cell to a date, the cell is given the text "Cannot parse to 
date".

Cells that store an error appear to be blank (as opposed to containing the 
original value or an error message) when editing them in the data table and a 
side note, produce a JavaScript error when clicked on (apologies, I cannot 
attached a screenshot due to exceeded quota).

To me, the semantics of "store-error" implies something is being stored, 
whether it's an error object - or the original value.

The following snippet is from toNumber():

                String s = args[0].toString();
                try {
                    return Double.parseDouble(s);
                } catch (NumberFormatException e) {
                    return new EvalError("Cannot parse to number");
                }

As you can see, all trace of the original string is gone. It seems appropriate 
to instead "flag" an error, while keeping the original value for inspection as 
to why it might have caused an error.

We've noticed an "annotate-rows" command which we found interesting (we 
imagined we could store our own key/values such as "error:true" in combination 
with "keep-original" for the onError value - but it seems as though Refine 
explicitly searches for the "flagged" and "starred" keys.

I suppose the issue I'm trying to raise is that if a value is going to become 
an error, it would be useful to be able to access it's original value.

Original issue reported on code.google.com by danpaulsmith on 23 Nov 2011 at 2:09

• Blocked on: #499

[GoogleCodeExporter]

Version 2386

Original comment by danpaulsmith on 23 Nov 2011 at 2:38

[GoogleCodeExporter]

That's a good idea, Dan. I have been thinking that we'll need several "layers" 
(like map layers) to store metadata. One "layer" already exists for 
reconciliation, but it should be generalized. So another layer could be for 
original values. But we need to think about what to do with it when yet another 
transformation is performed on cells that already contain errors.

Original comment by dfhu...@gmail.com on 27 Nov 2011 at 10:26

[GoogleCodeExporter]

+1 for generalising layers.

I might be missing something, but I'd expect a transform on an error to always 
be an error?

We only have a small use case for this issue, so we'll workaround it using 
"keep-original" and a makeshift error flag.

Thanks!

Original comment by danpaulsmith on 28 Nov 2011 at 11:32

[GoogleCodeExporter]

A transform on an error is usually an error, unless the expression tests for 
error and returns a normal value. But the issue is whether the original value 
of the first error is kept, or the "original value" is now the first error 
itself.

Original comment by dfhu...@gmail.com on 29 Nov 2011 at 8:02

[GoogleCodeExporter]

Original comment by dfhu...@gmail.com on 29 Nov 2011 at 8:05

• Changed state: Accepted