[AVRO-1600] GenericData#getDefaultValue(Field) behavior inconsistent with javadoc comment when default value is not defined

• Type: Bug
• Status: Open
• Priority: Trivial
• Resolution: Unresolved
• Affects Version/s: 1.7.4, 1.7.7
• Component/s: java
• Tags: default value
• Assignee: Unassigned
• Reporter: Alfonso Nishikawa Muñumer
• Created: 03/Nov/14 11:05
• Updated: 31/May/23 10:30

Description

The behavior of GenericData#getDefaultValue(Field) when the default value is not defined in the schema is to throw an AvroRuntimeException.
The javadoc comment states that should return null in this case. This can be seen here:

  /**
   * Gets the default value of the given field, if any.
   * @param field the field whose default value should be retrieved.
   * @return the default value associated with the given field, 
   * or null if none is specified in the schema.
   */
  @SuppressWarnings({ "rawtypes", "unchecked" })
  public Object getDefaultValue(Field field) {    
    JsonNode json = field.defaultValue();
    if (json == null)
      throw new AvroRuntimeException("Field " + field
                                     + " not set and has no default value");

This behavior affects RecordBuilderBase#defaultValue(Field) which expects a null too, as stated in it's javadoc comment:

  /**
   * Gets the default value of the given field, if any.
   * @param field the field whose default value should be retrieved.
   * @return the default value associated with the given field, 
   * or null if none is specified in the schema.
   * @throws IOException 
   */
  @SuppressWarnings({ "rawtypes", "unchecked" })
  protected Object defaultValue(Field field) throws IOException {    
    return data.deepCopy(field.schema(), data.getDefaultValue(field));
  }

Fix options:

• Modify the javadoc to comment it throws a runtime exception (and people should take this into account).
• Modify the method to return a null as stated in the javadoc comment.
• Modify the method to return null when the field is nullable and the default value is not defined, and update javadoc. (was this the original intended behavior?)