You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@avro.apache.org by Francis Galiegue <fg...@gmail.com> on 2013/02/27 05:02:37 UTC
Design decision question about the Avro Java API
Hello,
The question is quite simple: why is SchemaParseException an unchecked
exception?
This complicates handling parsing errors quite a bit, especially since
it doesn't make the distinction between actual parsing errors and
schema logic errors. For instance, this:
final String input = "\"astring\"";
throws a parsing exception, even though this is valid JSON (but not a
valid schema). And this:
final String input = "string";
also throws a parsing exception, but this time for a good reason,
since this is not valid JSON.
Are there plans to separate these exceptions, and more important, are
there plans to turn these into checked exceptions?
--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Re: Design decision question about the Avro Java API
Posted by Tatu Saloranta <ts...@gmail.com>.
On Wed, Feb 27, 2013 at 10:42 AM, Francis Galiegue <fg...@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 7:34 PM, Tatu Saloranta <ts...@gmail.com> wrote:
> [...]
>>>
>>> Well, to have user code be aware that it can fail, for one ;)
>>
>> Unchecked exceptions are no uncatchable exceptions, so you can catch
>> them as well as checked ones can't you?
>>
>
> Sure, but this is not good practice for one, and it can lead to very
> nasty surprises when it fails -- in production, otherwise it's not
> funny ;)
>
> I catch it right now, but I'd rather my IDE tells me that "hey, it can
> fail here, deal with that" -- and I do.
I do not have strong opinion myself on check vs unchecked exceptions,
but just so know, many Java developers are religiously AGAINST use of
checked exceptions, and consider their use a bad practice.
At best it can be said that this is a controversial question. Feel
free to google to see what I mean.
So it is good to be careful when claiming (as a fact) that doing
something is a bad practice.
It might just be your personal preference.
-+ Tatu +-
Re: Design decision question about the Avro Java API
Posted by Francis Galiegue <fg...@gmail.com>.
On Wed, Feb 27, 2013 at 7:34 PM, Tatu Saloranta <ts...@gmail.com> wrote:
[...]
>>
>> Well, to have user code be aware that it can fail, for one ;)
>
> Unchecked exceptions are no uncatchable exceptions, so you can catch
> them as well as checked ones can't you?
>
Sure, but this is not good practice for one, and it can lead to very
nasty surprises when it fails -- in production, otherwise it's not
funny ;)
I catch it right now, but I'd rather my IDE tells me that "hey, it can
fail here, deal with that" -- and I do.
--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Re: Design decision question about the Avro Java API
Posted by Tatu Saloranta <ts...@gmail.com>.
On Wed, Feb 27, 2013 at 10:17 AM, Francis Galiegue <fg...@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 7:09 PM, Doug Cutting <cu...@apache.org> wrote:
>> On Tue, Feb 26, 2013 at 8:02 PM, Francis Galiegue <fg...@gmail.com> 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 ;)
Unchecked exceptions are no uncatchable exceptions, so you can catch
them as well as checked ones can't you?
-+ Tatu +-
Re: Design decision question about the Avro Java API
Posted by Eric Sammer <es...@cloudera.com>.
I'll stay away from the checked vs. unchecked debate (that bikeshed looks
like a rainbow at this point), but I don't think adding another method
makes it any clearer. A bunch of folks will just be confused as to which
method they should call. I don't think this is an API problem as much as a
lack of documentation problem. I'd prefer we not add any additional choices
or complexity to the Java APIs; they're a bear already.
On Wed, Feb 27, 2013 at 11:02 AM, Doug Cutting <cu...@apache.org> wrote:
> On Wed, Feb 27, 2013 at 10:47 AM, Francis Galiegue <fg...@gmail.com>
> wrote:
> > Yes, I think that would be a nice to-have -- and a warning that this
> > exception is unchecked, too?
>
> +1 Yes, also emphasizing that the exception is unchecked would be good.
>
> Doug
>
--
Eric Sammer
twitter: esammer
data: www.cloudera.com
Re: Design decision question about the Avro Java API
Posted by Doug Cutting <cu...@apache.org>.
On Wed, Feb 27, 2013 at 10:47 AM, Francis Galiegue <fg...@gmail.com> wrote:
> Yes, I think that would be a nice to-have -- and a warning that this
> exception is unchecked, too?
+1 Yes, also emphasizing that the exception is unchecked would be good.
Doug
Re: Design decision question about the Avro Java API
Posted by Francis Galiegue <fg...@gmail.com>.
On Wed, Feb 27, 2013 at 7:45 PM, Doug Cutting <cu...@apache.org> wrote:
> On Wed, Feb 27, 2013 at 10:17 AM, Francis Galiegue <fg...@gmail.com> wrote:
>> Well, to have user code be aware that it can fail, for one ;)
>
> Nearly any API call can fail. Perhaps we should add it to the throws
> clause of the method, so it's better documented and more folks think
> to catch it?
>
Yes, I think that would be a nice to-have -- and a warning that this
exception is unchecked, too?
--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Re: Design decision question about the Avro Java API
Posted by Doug Cutting <cu...@apache.org>.
On Wed, Feb 27, 2013 at 10:17 AM, Francis Galiegue <fg...@gmail.com> wrote:
> Well, to have user code be aware that it can fail, for one ;)
Nearly any API call can fail. Perhaps we should add it to the throws
clause of the method, so it's better documented and more folks think
to catch it?
> What do you think of my .parseChecked() proposal above?
Personally I think it complicates the API & implementation with little
benefit. But if enough others disagree I could be persuaded
otherwise.
Doug
Re: Design decision question about the Avro Java API
Posted by Francis Galiegue <fg...@gmail.com>.
On Wed, Feb 27, 2013 at 7:09 PM, Doug Cutting <cu...@apache.org> wrote:
> On Tue, Feb 26, 2013 at 8:02 PM, Francis Galiegue <fg...@gmail.com> 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, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Re: Design decision question about the Avro Java API
Posted by Doug Cutting <cu...@apache.org>.
On Tue, Feb 26, 2013 at 8:02 PM, Francis Galiegue <fg...@gmail.com> 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?
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.
Doug