-Re: Design decision question about the Avro Java API
Francis Galiegue 2013-02-27, 18:17
On Wed, Feb 27, 2013 at 7:09 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 26, 2013 at 8:02 PM, Francis Galiegue <[EMAIL PROTECTED]> wrote:
>> Are there plans to separate these exceptions, and more important, are
>> there plans to turn these into checked exceptions?
> There are no such plans that I am aware of.
> Changing SchemaParseException to a checked exception would be an
> incompatible change, breaking a lot of user code, so folks are likely
> to resist. What would such a change make possible that is not
> possible today?
Well, to have user code be aware that it can fail, for one ;)
Why not .parseChecked(), then, which would throw a checked exception?
Usually it would be the reverse (ie, .parse() and .parseUnchecked())
but it's too late, I guess.
Right now, I need to catch SchemaParseException, _and_ see if there is
anything in .getCause() to see whether it is a parse error. Ideally, I
* the plain JsonParseException thrown if the input is invalid,
* an InvalidAvroSchemaException if the input is valid _but_ there is a
logic error in the schema.
> Splitting cases where this exception is thrown could be done
> compatibly with subclasses, so if this is useful and not difficult to
> accomplish then I doubt folks would object.
What do you think of my .parseChecked() proposal above?
Francis Galiegue, [EMAIL PROTECTED]
JSON Schema in Java: http://json-schema-validator.herokuapp.com