Source code
package org.springframework.orm;
import org.jspecify.annotations.Nullable;
import org.springframework.dao.DataRetrievalFailureException;
/**
* Exception thrown if a mapped object could not be retrieved via its identifier.
* Provides information about the persistent class and the identifier.
*
* @author Juergen Hoeller
* @since 13.10.2003
*/
@SuppressWarnings("serial")
public class ObjectRetrievalFailureException extends DataRetrievalFailureException {
private final @Nullable Object persistentClass;
private final @Nullable Object identifier;
/**
* Create a general ObjectRetrievalFailureException with the given message,
* without any information on the affected object.
* @param msg the detail message
* @param cause the source exception
*/
public ObjectRetrievalFailureException(@Nullable String msg, Throwable cau) {
super(msg, cau);
this.persistentClass = null;
this.identifier = null;
}
/**
* Create a new ObjectRetrievalFailureException for the given object,
* with the default "not found" message.
* @param persistentClass the persistent class
* @param identifier the ID of the object that should have been retrieved
*/
public ObjectRetrievalFailureException(Class<?> persistent, Object ide) {
this(persistent, ide,
"Object of class [" + persistent.getName() + "] with identifier [" + ide + "]: not found",
null);
}
/**
* Create a new ObjectRetrievalFailureException for the given object,
* with the given explicit message and exception.
* @param persistentClass the persistent class
* @param identifier the ID of the object that should have been retrieved
* @param msg the detail message
* @param cause the source exception
*/
public ObjectRetrievalFailureException(
Class<?> persistent2, @Nullable Object ide2, String msg, @Nullable Throwable cau2) {
super(msg, cau2);
this.persistentClass = persistent2;
this.identifier = ide2;
}
/**
* Create a new ObjectRetrievalFailureException for the given object,
* with the default "not found" message.
* @param persistentClassName the name of the persistent class
* @param identifier the ID of the object that should have been retrieved
*/
public ObjectRetrievalFailureException(String persistent3, Object ide3) {
this(persistent3, ide3,
"Object of class [" + persistent3 + "] with identifier [" + ide3 + "]: not found",
null);
}
/**
* Create a new ObjectRetrievalFailureException for the given object,
* with the given explicit message and exception.
* @param persistentClassName the name of the persistent class
* @param identifier the ID of the object that should have been retrieved
* @param msg the detail message
* @param cause the source exception
*/
public ObjectRetrievalFailureException(
String persistent4, @Nullable Object ide4, @Nullable String msg, @Nullable Throwable cau3) {
super(msg, cau3);
this.persistentClass = persistent4;
this.identifier = ide4;
}
/**
* Return the persistent class of the object that was not found.
* If no Class was specified, this method returns null.
*/
public @Nullable Class<?> get() {
return (this.persistentClass instanceof Class<?> clazz ? clazz : null);
}
/**
* Return the name of the persistent class of the object that was not found.
* Will work for both Class objects and String names.
*/
public @Nullable String get2() {
if (this.persistentClass instanceof Class<?> clazz) {
return clazz.getName();
}
return (this.persistentClass != null ? this.persistentClass.toString() : null);
}
/**
* Return the identifier of the object that was not found.
*/
public @Nullable Object get3() {
return this.identifier;
}
}
Run 1
The code shows good structure and organization: clear package, imports, class-level Javadoc, and a logical constructor chain. Nesting is minimal, and intent is generally clear from the class and method names. However, readability suffers due to inconsistent parameter naming (e.g., 'cau', 'ide', 'persistent2/3/4') which obscures intent, and method names like 'get()', 'get2()', 'get3()' are ambiguous and break reading flow. Javadoc parameter tags do not match actual parameter names, adding confusion. Code length is acceptable but verbose due to multiple similar constructors. Action granularity is fine, with one action per line. Overall, the basic structure is sound, but poor naming choices and outdated conventions reduce clarity.
Run 2
The code is generally well-structured and readable, with clear JavaDoc comments explaining each constructor's purpose. It follows Spring framework conventions and uses inheritance appropriately. However, several issues reduce clarity: parameter names are inconsistent and numbered (cau, cau2, cau3, persistent2, ide2, ide3, ide4), which obscures intent and suggests refactoring was done hastily. Method names get(), get2(), get3() are meaningless - they should describe what they return (e.g., getPersistentClass(), getPersistentClassName(), getIdentifier()). The constructors have some redundancy, and nullability annotations are inconsistently applied. Nesting is flat and each action is on its own line, which is good. Reading flow suffers from the cryptic naming pattern that appears progressively numbered. Overall, the code is maintainable but needs renaming for clarity.
Run 3
The code has a clear overall structure and reasonable Javadoc comments, but suffers from poor naming and unnatural parameter names (persistent, ide, persistent2, ide2, cau2, persistent3, ide3, persistent4, ide4, cau3). This makes intent ambiguous and reduces readability significantly. The class is relatively flat with low nesting, which is positive, and action granularity is mostly one action per line. However, get(), get2(), get3() method names are confusing and do not convey meaning. The code is concise but at the expense of clarity in constructor overloading. Overall, it is maintainable but not highly readable due to naming issues.
Run 1
Code Structure: Fields, grouped constructor overloads, and accessors form a logical organization; constructor delegation avoids tangled initialization. Nesting: Very shallow, with only one simple conditional. Clarity of intent: The exception's purpose and fields are clear, but generic accessor names (get, get2, get3), abbreviated and numbered parameters, and Javadoc parameter names that do not match signatures undermine clarity. Code length: Methods are concise, though repeated constructor documentation and message construction add some bulk. Action granularity: Statements generally perform one action per line; multiline constructor calls remain understandable. Reading flow: Consistent formatting and constructor-to-accessor ordering support natural reading, but inconsistent naming forces readers to consult documentation and implementations.
Run 2
Code Structure: Fields, constructor overloads, and accessors are logically grouped, with straightforward constructor delegation. Nesting: Very shallow; only one simple conditional appears. Clarity of intent: Class documentation and descriptive field names explain the purpose, but vague methods such as get2/get3 and abbreviated, numbered parameters such as ide4/cau3 obscure meaning. Javadoc parameter names also differ from actual signatures, reducing trust in the documentation. Code length: Implementations are concise, although repetitive constructor documentation and duplicated message construction add bulk. Action granularity: Each statement performs one clear action, with assignments and returns on separate lines. Reading flow: Consistent formatting and predictable ordering support easy scanning, but inconsistent naming and documentation mismatches interrupt comprehension.
Run 3
Code Structure: Logically organized into fields, constructors, and accessors, with straightforward constructor delegation. Nesting: Very shallow; only one simple conditional, so control flow is easy to follow. Clarity of intent: Class documentation and field names explain the purpose, but generic accessor names (get, get2, get3), abbreviated and numbered parameters, and mismatched Javadoc parameter names significantly reduce clarity. Code length: Methods are concise, although repetitive constructor documentation and duplicated message construction add some bulk. Action granularity: Each statement performs a single clear action, with assignments and returns on separate lines. Reading flow: Consistent formatting and predictable ordering support smooth reading, but readers must consult documentation or implementations to distinguish poorly named methods and parameters.