juicedata/juicefs · error

unrecognized error handling value

Error message

unrecognized error handling value

What it means

Raised by the Java bridge's Push method in sdk/java/libjfs/bridge.go:194. Push takes an error-handling mode; when the mode is not Stop or ContinueOnError, the code panics with this message. This is a programming/configuration error in the caller of the bridge, not a runtime data error — the bridge only recognizes its defined errorHandling values.

Source

Thrown at sdk/java/libjfs/bridge.go:194

				for k, v := range b.commonLabels {
					metric.Label = append(metric.Label, &dto.LabelPair{
						Name:  proto.String(k),
						Value: proto.String(v),
					})
				}
			}
		}
	}
	if err != nil || len(mfs) == 0 {
		switch b.errorHandling {
		case AbortOnError:
			return err
		case ContinueOnError:
			if b.logger != nil {
				b.logger.Println("continue on error:", err)
			}
		default:
			panic("unrecognized error handling value")
		}
	}

	conn, err := net.DialTimeout("tcp", b.url, b.timeout)
	if err != nil {
		return err
	}
	defer conn.Close()

	return writeMetrics(conn, mfs, b.useTags, b.prefix, model.Now())
}

func writeMetrics(w io.Writer, mfs []*dto.MetricFamily, useTags bool, prefix string, now model.Time) error {
	vec, err := expfmt.ExtractSamples(&expfmt.DecodeOptions{
		Timestamp: now,
	}, mfs...)
	if err != nil {
		return err

View on GitHub (pinned to c9a67b23e8)

Solutions

1. Pass only the recognized values: the constant for Stop (0) or ContinueOnError (1) as defined in the bridge.
2. Use the Java SDK's enum/constant helpers instead of raw integers when calling Push.
3. Align the Java SDK and native libjfs library versions so errorHandling codes match.
4. Add validation on the Java side to reject unknown modes before crossing the JNI boundary.

Example fix

// before
bridge.Push(cfg, 7) // unknown handling value -> panic

// after
bridge.Push(cfg, bridge.ContinueOnError) // recognized constant

// Java side, before calling Push
if (errorHandling != ERROR_HANDLING_STOP && errorHandling != ERROR_HANDLING_CONTINUE) {
    throw new IllegalArgumentException("errorHandling must be 0 (stop) or 1 (continue-on-error), got " + errorHandling);
}

// Go side, defensively validate before the bridge switch
if h != Stop && h != ContinueOnError {
    return fmt.Errorf("unsupported error handling value: %v", h)
}

When it happens

Trigger: Invoking bridge Push (e.g. from Java via JNI for juicefs sync) with an unrecognized errorHandling value — typically a wrong integer constant passed across the JNI boundary or a stale/unsupported enum value from the Java side.

Common situations: Java SDK versions mismatched with the native library (libjfs.so) so the errorHandling enum codes disagree; hand-written JNI callers passing 2/other values instead of 0 (Stop) or 1 (ContinueOnError).

Understand the failure class

Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.

Related errors

• write
• Invalid start or len parameter
• stream was closed
• arguments: " + off + " " + len
• position is negative

AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06). Data as JSON: /api/errors/60249600fab5a832. Report an issue: GitHub.