Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> Design decision question about the Avro Java API

Copy link to this message
Re: Design decision question about the Avro Java API
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
would see:

* 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