Francis Galiegue
2013-02-27, 04:02
Doug Cutting
2013-02-27, 18:09
Francis Galiegue
2013-02-27, 18:17
Tatu Saloranta
2013-02-27, 18:34
Francis Galiegue
2013-02-27, 18:42
Doug Cutting
2013-02-27, 18:45
Francis Galiegue
2013-02-27, 18:47
Tatu Saloranta
2013-02-27, 19:00
Doug Cutting
2013-02-27, 19:02
Eric Sammer
2013-03-04, 08:16
-
Design decision question about the Avro Java APIFrancis Galiegue 2013-02-27, 04:02
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, [EMAIL PROTECTED]
JSON Schema in Java: http://json-schema-validator.herokuapp.com
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, [EMAIL PROTECTED]
JSON Schema in Java: http://json-schema-validator.herokuapp.com
-
Re: Design decision question about the Avro Java APIDoug Cutting 2013-02-27, 18:09
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?
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
> 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
-
Re: Design decision question about the Avro Java APIFrancis 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
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
> 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
-
Re: Design decision question about the Avro Java APITatu Saloranta 2013-02-27, 18:34
On Wed, Feb 27, 2013 at 10:17 AM, Francis Galiegue <[EMAIL PROTECTED]> wrote:
> 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 ;)
Unchecked exceptions are no uncatchable exceptions, so you can catch
them as well as checked ones can't you?
-+ Tatu +-
> 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 ;)
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 APIFrancis Galiegue 2013-02-27, 18:42
On Wed, Feb 27, 2013 at 7:34 PM, Tatu Saloranta <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
JSON Schema in Java: http://json-schema-validator.herokuapp.com
[...]
>>
>> 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, [EMAIL PROTECTED]
JSON Schema in Java: http://json-schema-validator.herokuapp.com
-
Re: Design decision question about the Avro Java APIDoug Cutting 2013-02-27, 18:45
On Wed, Feb 27, 2013 at 10:17 AM, Francis Galiegue <[EMAIL PROTECTED]> 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
> 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 APIFrancis Galiegue 2013-02-27, 18:47
On Wed, Feb 27, 2013 at 7:45 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2013 at 10:17 AM, Francis Galiegue <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
JSON Schema in Java: http://json-schema-validator.herokuapp.com
> On Wed, Feb 27, 2013 at 10:17 AM, Francis Galiegue <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
JSON Schema in Java: http://json-schema-validator.herokuapp.com
-
Re: Design decision question about the Avro Java APITatu Saloranta 2013-02-27, 19:00
On Wed, Feb 27, 2013 at 10:42 AM, Francis Galiegue <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2013 at 7:34 PM, Tatu Saloranta <[EMAIL PROTECTED]> 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 +-
> On Wed, Feb 27, 2013 at 7:34 PM, Tatu Saloranta <[EMAIL PROTECTED]> 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 APIDoug Cutting 2013-02-27, 19:02
On Wed, Feb 27, 2013 at 10:47 AM, Francis Galiegue <[EMAIL PROTECTED]> 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
> 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 APIEric Sammer 2013-03-04, 08:16
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 <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2013 at 10:47 AM, Francis Galiegue <[EMAIL PROTECTED]>
> 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
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 <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2013 at 10:47 AM, Francis Galiegue <[EMAIL PROTECTED]>
> 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
