Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: java
    • Labels:
      None

      Description

      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

        Activity

        Yang Yang created issue -
        Hide
        James Baldassari added a comment -

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

        From Doug Cutting:

        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.

        From Scott Carey:

        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.

        Show
        James Baldassari added a comment - Adding some comments from the e-mail thread about this issue: From Doug Cutting: 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. From Scott Carey: 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Yang Yang
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development