You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "James Baldassari (Commented) (JIRA)" <ji...@apache.org> on 2011/10/28 00:36:32 UTC

[jira] [Commented] (AVRO-885) explicit schema verification

    [ https://issues.apache.org/jira/browse/AVRO-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13137665#comment-13137665 ] 

James Baldassari commented on AVRO-885:
---------------------------------------

Adding some comments from the e-mail thread about this issue:

>From Doug Cutting:
{quote}
I see three choices, none perfect:

 1. Use a subclass of NullPointerException in both builder and
non-builder code.  This provides consistency and back-compatibility, but
does not permit folks to catch all Avro runtime exceptions with a single
clause.

 2. Use a subclass of AvroRuntimeException in both builder and
non-builder code.  This would not be backwards compatible, but would
provide consistency and permits folks to catch all Avro runtime
exceptions with a single clause.

 3. Throw one exception from the builder code and a different exception
from the non-builder code.

My instinct is to go with (1).  Folks can always add a second catch
clause if they wish to distinguish Avro runtime exceptions from other
runtime exceptions.  I'm not sure that distinction is always meaningful
anyway, since Avro might already throw other runtime exceptions that are
not subclasses of AvroRuntimeException.
{quote}

>From Scott Carey:
{quote}
Before the SpecificRecord  Builder API, a common practice was to use wrapper classes and/or static helpers for your types so that users can only create valid objects.
{quote}
                
> explicit schema verification
> ----------------------------
>
>                 Key: AVRO-885
>                 URL: https://issues.apache.org/jira/browse/AVRO-885
>             Project: Avro
>          Issue Type: Improvement
>          Components: java
>            Reporter: Yang Yang
>            Priority: Minor
>
> when we declare some fields in a record, it's assumed to be mandatory unless we specify it with a union {original_type, null}.
> this feature is actually very useful to me: I declare a schema, and if some new user creates a record, but fails to populate some mandatory field, I want some mechanism to throw an exception.
> currently I get this feature "by accident": if the user misses some mandatory fields, when I send this record as a param to some RPC method, or when I serialize it through SpecificDatumWriter, Avro throws a NULLPointerException.  I can catch this and let user know that it's due to lack of mandatory fields.
> but instead of NPE, could we make Avro throw a more explicit exception, so it's more descriptive?
> Thanks
> Yang
> On 09/07/2011 01:17 PM, Yang wrote:
> > but instead of NPE, could we make Avro throw a more explicit exception,
> > so it's more descriptive?
> This is possible.  It could be done back-compatibly by throwing a
> subclass of NullPointerException, e.g., AvroNullValueException.  The
> logic in question is in GenericDatumWriter, where Avro builds an error
> message indicating the path to the null in the data.
> Please file an issue in Jira for this.
> Doug

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira