Source code
package org.springframework.orm;
import org.jspecify.annotations.Nullable;
import org.springframework.dao.DataRetrievalFailureException;
@SuppressWarnings("serial")
public class ObjectRetrievalFailureException extends DataRetrievalFailureException {
private final @Nullable Object persistentClass;
private final @Nullable Object identifier;
public ObjectRetrievalFailureException(@Nullable String msg, Throwable cause) {
super(msg, cause);
this.persistentClass = null;
this.identifier = null;
}
public ObjectRetrievalFailureException(Class<?> persistentClass, Object identifier) {
this(persistentClass, identifier,
"Object of class [" + persistentClass.getName() + "] with identifier [" + identifier + "]: not found",
null);
}
public ObjectRetrievalFailureException(
Class<?> persistentClass, @Nullable Object identifier, String msg, @Nullable Throwable cause) {
super(msg, cause);
this.persistentClass = persistentClass;
this.identifier = identifier;
}
public ObjectRetrievalFailureException(String persistentClassName, Object identifier) {
this(persistentClassName, identifier,
"Object of class [" + persistentClassName + "] with identifier [" + identifier + "]: not found",
null);
}
public ObjectRetrievalFailureException(
String persistentClassName, @Nullable Object identifier, @Nullable String msg, @Nullable Throwable cause) {
super(msg, cause);
this.persistentClass = persistentClassName;
this.identifier = identifier;
}
public @Nullable Class<?> getPersistentClass() {
return (this.persistentClass instanceof Class<?> clazz ? clazz : null);
}
public @Nullable String getPersistentClassName() {
if (this.persistentClass instanceof Class<?> clazz) {
return clazz.getName();
}
return (this.persistentClass != null ? this.persistentClass.toString() : null);
}
public @Nullable Object getIdentifier() {
return this.identifier;
}
}
Run 1
The code is generally readable but has some issues. The class structure is logical, extending DataRetrievalFailureException with clear field names and appropriate @Nullable annotations. Constructors are well-organized with proper delegation between them. However, there are several readability problems: excessive blank lines between members (some sections have 10+ empty lines), which disrupts natural reading flow. The fluent getter methods use pattern matching effectively but the ternary expressions could be clearer. The constructor parameters alternate between Class<?> and String types for persistentClass, which may cause confusion. Action granularity is mostly one action per line, but the constructor calls with string concatenation are dense. The code length is reasonable for what it does, though the error message construction is duplicated. The nesting is minimal, which is good. Overall structure is sound but the inconsistent spacing and some complex expressions prevent a higher score.
Run 2
The code is well-structured as a simple exception class with clear purpose. Constructors are logically organized and delegate appropriately, showing good action granularity. Nesting is minimal—only one conditional level in getPersistentClassName. Reading flow is natural, with fields, constructors, and accessors in conventional order. The main readability issue is excessive blank lines between members (7–10 empty lines), which disrupts visual flow and makes the file longer than necessary. Method names clearly express intent. The ternary and instanceof pattern in getPersistentClass is concise but slightly less immediately readable than an if-else. Overall, the code is clean and maintainable, but the formatting inconsistency with excessive vertical whitespace prevents a higher score.
Run 3
The code is generally readable with clear structure and intent. It follows a logical organization with fields, constructors, and getters. The exception class is concise and each constructor serves a distinct purpose. However, there are several readability issues: excessive blank lines between methods create unnecessary visual gaps, the constructors with multiple parameters could benefit from better formatting, and the getPersistentClass() method has a somewhat convoluted cast expression. The nesting is shallow, which is good. Action granularity is mostly one action per line. The reading flow is natural but disrupted by the excessive spacing. The code would be more readable with consistent method spacing and slightly cleaner type handling in getter methods.
Run 1
Code Structure: Fields, constructor overloads, and getters are logically organized; constructor delegation reduces duplication. Nesting: Very shallow, with only one simple conditional. Clarity of intent: Descriptive class and method names clearly communicate retrieval failure details, although storing either a Class or a String in an Object field requires readers to infer its dual role. Code length: Methods are concise, but excessive blank lines unnecessarily expand the code, and similar constructors repeat initialization and message formatting. Action granularity: Statements generally perform one action per line; ternary expressions remain straightforward. Reading flow: The ordering is natural and formatting is consistent within methods, but large whitespace gaps interrupt scanning.
Run 2
Code Structure: Fields, constructors, and getters are logically grouped, with constructor delegation reducing duplication. Nesting: Almost entirely flat, with only one simple conditional. Clarity of intent: Descriptive class, method, and parameter names make the exception's purpose clear; using Object to represent either a Class or class name slightly weakens type clarity. Code length: Methods are concise, but excessive blank lines unnecessarily inflate the listing, and parallel constructor overloads repeat some logic. Action granularity: Each statement performs a single clear action, while multiline constructor calls remain readable. Reading flow: Conventional Java organization and consistent indentation support natural reading, though large whitespace gaps interrupt continuity.
Run 3
Code Structure: Fields, constructor overloads, and getters are logically organized, with constructor delegation reducing duplication. Nesting: Minimal; only one shallow conditional appears. Clarity of intent: Descriptive class and method names make the exception's purpose clear, though storing either a Class or String in an Object field requires some interpretation. Code length: Methods are concise, but excessive blank lines unnecessarily lengthen the file, and error-message construction is duplicated. Action granularity: Statements generally perform one action per line; multiline constructor calls remain easy to follow. Reading flow: Ordering and consistent indentation support natural reading, but large whitespace gaps interrupt continuity.