sshyran / genxdm

Automatically exported from code.google.com/p/genxdm
0 stars 0 forks source link

When a pattern constraint fails, throw a DatatypeException with a PatternException as a cause. #110

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I found that when pattern constraint is failing than the thrown 
DatatypeException does not contain the cause or any other info that a user's 
program can use to determine this condition. In SimpleTypeImpl class, 
checkPatternFacets method:

            while (true)
            {
                ...
                    for (final Pattern pattern : currentType.getPatterns())
                    {
                        size++;
                        try
                        {
                            pattern.validate(normalizedValue);
                            pass++;
                        }
                        catch (final PatternException e)
                        {
                            // Ignore.
                        }
                    }
                    if (size > 0 && pass == 0)
                    {
                        throw new DatatypeException(normalizedValue, simpleType); <---- here....
                    }
                }

Something should be passed as a cause...(PatternException?)

Original issue reported on code.google.com by yury.ska...@gmail.com on 26 Oct 2012 at 7:43

GoogleCodeExporter commented 8 years ago
Fixed for the simple case in r410.

The above is rather simplistic: we can't simply keep the last-thrown exception 
and expect it to be interesting; when there's more than one pattern at a 
derivation step, all of the patterns are or-d together, which is why this has 
the otherwise odd logic that it has (the size parameter is unnecessary, btw).

r410 handles the single-pattern case, which is probably commonest, passing the 
generated PatternException as the cause to DatatypeException. The more complex 
case would require collecting *all* of the failure indicators (the 
PatternExceptions), wrapping them in a pattern-exception-collector-exception, 
and setting that as the cause.

Marking as fixed (it's fixed for the simple case). Reopen if the more complex 
case matters enough; that will have to wait for someone to write the 
exception-that-collects-exceptions-in-parallel-rather-than-in-series wrapper.

Original comment by aale...@gmail.com on 26 Oct 2012 at 7:54