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 a, Throwable b) {
super(a, b);
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<?> c, Object d) {
this(c, d,
"Object of class [" + c.getName() + "] with identifier [" + d + "]: 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<?> e, @Nullable Object f, String g, @Nullable Throwable h) {
super(g, h);
this.persistentClass = e;
this.identifier = f;
}
/**
* 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 i, Object j) {
this(i, j,
"Object of class [" + i + "] with identifier [" + j + "]: 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 k, @Nullable Object l, @Nullable String m, @Nullable Throwable n) {
super(m, n);
this.persistentClass = k;
this.identifier = l;
}
/**
* Return the persistent class of the object that was not found.
* If no Class was specified, this method returns null.
*/
public @Nullable Class<?> a() {
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 b() {
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 c() {
return this.identifier;
}
}
Run 1
While the code has a clear class structure and documentation, readability is severely compromised. The most significant issue is the use of meaningless, single-letter variable names (a, b, c, d, e, f, etc.) for constructor parameters and method names (a(), b(), c()), which obscures intent and violates clarity. Despite the Javadocs describing the parameters, the code itself is ambiguous. The action granularity is acceptable, and nesting is minimal, but the reading flow is disrupted by these opaque names. The code length is reasonable for an exception class with multiple constructors. Overall, the structure and documentation are good, but the naming choices drastically reduce readability.
Run 2
The code structure is logically organized as an exception hierarchy class, but readability is severely impacted by poor variable naming (a, b, c, d, e, f, g, h, i, j, k, l, m, n) and method names (a(), b(), c()) that completely obscure the intent. This appears to be deliberately obfuscated code masquerading as Spring source. The Javadoc comments provide clear documentation, but they do not match the actual parameter names, creating a disconnect between documentation and implementation. While nesting is flat and action granularity is generally one action per line, the reading flow is unnatural because readers must constantly map meaningless names to their documented purposes. The class has reasonable length and structure, but the naming choices render it nearly unreadable despite clean formatting.
Run 3
The code has good structure and flat nesting, but readability is seriously undermined by meaningless parameter names (a, b, c, d, e, f, g, h, i, j, k, l, m, n) and method names (a(), b(), c()). While the Javadoc comments clarify intent, the names contradict the documented purpose, making the code ambiguous. Action granularity is mostly one action per line, and reading flow is natural due to sequential constructors and getters. However, the unnamed parameters make it difficult to understand what each constructor expects without reading documentation. Code length is appropriate but slightly verbose due to overloaded constructors. The class-level Javadoc is clear, but the implementation fails to maintain clarity through proper naming conventions.
Run 1
Code Structure: Logically organized into fields, constructor overloads, and accessors, with consistent formatting. Nesting: Very shallow; a single conditional and straightforward ternaries are easy to follow. Clarity of intent: The class name, field names, and documentation explain the purpose, but single-letter parameters and accessor names obscure meaning. Javadoc parameter names do not match actual parameters, further reducing clarity. Code length: Methods are concise and constructor delegation avoids redundant initialization, although repeated documentation and similar overloads add length. Action granularity: Each statement performs one clear action, with no crowded multi-statement lines. Reading flow: The progression from initialization to retrieval is natural, but readers must repeatedly consult documentation to interpret anonymous-looking names.
Run 2
Code Structure: Fields, related constructor overloads, and accessors are logically grouped, with constructor delegation avoiding duplicated initialization. Nesting: Very shallow; only one simple conditional appears. Clarity of intent: The class name, descriptive fields, and documentation explain the purpose, but single-letter parameters and accessor names obscure meaning. Javadoc parameter names also fail to match actual signatures, making the documentation misleading. Code length: Implementations are concise, although repeated constructor documentation and extra blank lines add bulk. Action granularity: Each statement performs one clear action; wrapped constructor calls remain understandable. Reading flow: Consistent formatting and predictable organization support easy scanning, but readers must repeatedly infer what anonymous parameters and methods represent.
Run 3
Code Structure: Fields, overloaded constructors, and accessors are logically grouped, with constructor delegation reducing duplication. Nesting: Very shallow; only one simple conditional appears. Clarity of intent: The class name, field names, and documentation explain the purpose, but single-letter parameters and accessor names obscure meaning. Javadoc parameter names also do not match actual signatures, making documentation misleading. Code length: Implementation is concise, though repeated constructor documentation and message construction add some bulk. Action granularity: Each statement performs one clear action; assignments and delegation are cleanly separated. Reading flow: Consistent formatting and predictable organization support easy reading, but cryptic names force readers to consult documentation and infer parameter roles.