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 age, Throwable count) {
super(age, count);
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<?> currentAccount, Object preference) {
this(currentAccount, preference,
"Object of class [" + currentAccount.getName() + "] with identifier [" + preference + "]: 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<?> currentSession, @Nullable Object nextClient, String map, @Nullable Throwable index) {
super(map, index);
this.persistentClass = currentSession;
this.identifier = nextClient;
}
/**
* 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 currentAddress, Object remoteUser) {
this(currentAddress, remoteUser,
"Object of class [" + currentAddress + "] with identifier [" + remoteUser + "]: 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 currentBalance, @Nullable Object localBatch, @Nullable String key, @Nullable Throwable token) {
super(key, token);
this.persistentClass = currentBalance;
this.identifier = localBatch;
}
/**
* Return the persistent class of the object that was not found.
* If no Class was specified, this method returns null.
*/
public @Nullable Class<?> validateRequest() {
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 validateBalance() {
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 validateScore() {
return this.identifier;
}
}
Run 1
The code structure and nesting are acceptable, but clarity of intent is severely compromised by inconsistent parameter names (e.g., 'age', 'count', 'currentAccount', 'preference', 'map', 'index') and method names (e.g., 'validateRequest', 'validateBalance', 'validateScore') that do not reflect their actual purpose. This makes the code ambiguous and hard to read. While the code length is concise and action granularity is fine, the reading flow is unnatural due to these misleading identifiers. The class has a clear general purpose, but the implementation details use unrelated business-like terms, violating reader expectations.
Run 2
The structure follows a standard exception class pattern, but parameter names are severely obfuscated (e.g., 'age', 'count', 'currentAccount', 'preference', 'map', 'index', 'currentBalance', 'localBatch', 'key', 'token'). These names completely obscure intent and bear no relation to the documented parameters (persistentClass, identifier, msg, cause). Method names like validateRequest(), validateBalance(), validateScore() suggest actions unrelated to retrieving persistent class information. The Javadoc is clear and well-formatted, but the code contradicts it, creating confusion. Nesting is minimal and length is acceptable, but reading flow is broken by mismatched naming. Action granularity is fine, but clarity of intent fails drastically.
Run 3
The code structure is logical for an exception class, but readability is severely undermined by nonsensical parameter and method names (e.g., 'age', 'count', 'currentAccount', 'preference', 'validateRequest', 'validateBalance') that bear no relation to their documented purposes. This creates a significant mismatch between Javadoc and implementation, making the intent ambiguous. Nesting is generally flat and action granularity is acceptable, but the naming issues force constant cross-referencing with comments. The code is not unnecessarily long, but reading flow is disrupted by the misleading identifiers. Overall, the class is understandable only because of the documentation, not the code itself.
Run 1
Code Structure: Logically organized into fields, constructor overloads, and accessors, with consistent formatting. Nesting: Very shallow; a single conditional and simple ternaries are easy to follow. Clarity of intent: The class purpose and stored fields are clear, but misleading parameter names such as age, count, and currentBalance obscure their roles. Accessor names like validateRequest imply validation rather than retrieval, and Javadoc parameter names do not match the signatures. Code length: Implementation is concise, although repeated constructor documentation adds bulk. Action granularity: Statements generally perform one action per line; multiline constructor calls remain readable. Reading flow: Constructor delegation and grouped accessors provide a natural progression, but readers must repeatedly reconcile misleading names with documentation and assignments.
Run 2
Code Structure: The exception class is logically organized into fields, constructors, and accessors, with sensible constructor delegation. Nesting: Control flow is nearly flat, with only one simple conditional. Clarity of intent: The class purpose and stored fields are clear, but misleading parameter names such as age, count, and currentBalance obscure their roles. Accessor names such as validateRequest and validateScore incorrectly suggest validation rather than retrieval. Javadoc parameter names do not match the signatures, further undermining clarity. Code length: Implementations are concise, although repetitive constructor documentation adds bulk. Action granularity: Statements generally perform one action per line; wrapped constructor calls remain readable. Reading flow: Consistent formatting and predictable organization support scanning, but readers must repeatedly reconcile documentation, names, and actual behavior.
Run 3
1. Code Structure: Fields, constructors, and accessors are logically grouped, with consistent formatting. 2. Nesting: Minimal nesting; the single conditional is straightforward. 3. Clarity of intent: The exception's purpose and fields are clear, but misleading parameter names such as age, count, and currentBalance obscure their roles. Accessor names validateRequest, validateBalance, and validateScore incorrectly suggest validation. Javadoc parameter names do not match actual signatures, further undermining clarity. 4. Code length: Methods are concise, although repetitive constructor documentation and overloads add reading overhead. 5. Action granularity: Statements generally perform one action per line; wrapped constructor calls remain understandable. 6. Reading flow: Organization and constructor delegation support natural reading, but inconsistent naming forces readers to repeatedly consult implementations and reconcile them with documentation.