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 cause) {
super(msg, cause); 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<?> persistentClass, Object identifier) {
this(persistentClass, identifier,
"Object of class [" + persistentClass.getName() + "] with identifier [" + identifier + "]: 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<?> persistentClass, @Nullable Object identifier, String msg, @Nullable Throwable cause) {
super(msg, cause);
this.persistentClass = persistentClass; this.identifier = identifier; }
/**
* 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 persistentClassName, Object identifier) {
this(persistentClassName, identifier, "Object of class [" + persistentClassName + "] with identifier [" + identifier + "]: 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 persistentClassName, @Nullable Object identifier, @Nullable String msg, @Nullable Throwable cause) {
super(msg, cause);
this.persistentClass = persistentClassName; this.identifier = identifier; }
/**
* Return the persistent class of the object that was not found.
* If no Class was specified, this method returns null.
*/
public @Nullable Class<?> getPersistentClass() {
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 getPersistentClassName() {
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 getIdentifier() { return this.identifier; }
}
Run 1
This code suffers from severe formatting issues that make it extremely difficult to read. Multiple statements are packed onto single lines (e.g., field declarations, constructor bodies, method bodies), violating the 'one action per line' principle. Import statements, annotations, and Javadoc are crammed together, obscuring the structure. While the logical organization of the class itself is reasonable (constructors, getters), the physical layout destroys any natural reading flow. Nesting is minimal, but the tangled formatting makes even simple methods hard to parse. The Javadoc comments exist but are visually lost in the clutter. Code length is acceptable, but the compression of lines makes it feel denser than necessary. The clarity of intent is severely reduced—readers must mentally reformat the code to understand it. Action granularity is poor, with multiple assignments and method returns on single lines. This appears to be a result of aggressive minification or poor auto-formatting, making it nearly unreadable despite the underlying logic being sound.
Run 2
The code's purpose and class-level documentation are clear, but readability suffers from severe formatting issues. Multiple statements are packed onto single lines, import and class declarations are compressed, and constructor/field assignments share lines, violating one-action-per-line and natural reading flow. The mixed placement of comments between method signatures disrupts logical flow. While the overall structure is standard, the cramped layout creates unnecessary cognitive load and makes the code appear tangled despite straightforward logic.
Run 3
The code has severe formatting issues that drastically reduce readability. Multiple statements are crammed onto single lines, especially in constructors and methods, violating the 'one action per line' principle. The class declaration and import statements are also compressed onto the same line. Javadoc comments are present but often appear inline with code, disrupting the natural reading flow. Nesting is minimal, which is good, but clarity of intent suffers because the abnormal formatting obscures the logical structure. Code length is reasonable, but the presentation makes it feel cluttered. Action granularity is poor: assignments and method calls are combined without line breaks. Reading flow is disorganized due to inconsistent spacing and the mixing of documentation with executable code. Overall, while the underlying logic is straightforward, the formatting obscures it significantly.
Run 1
Code Structure: Logically organized exception class with fields, related constructor overloads, and accessors, though compressed formatting obscures boundaries. Nesting: Very shallow, with only one simple conditional. Clarity of intent: Descriptive names, explicit nullability annotations, and useful Javadoc make the purpose clear; storing either a Class or String in an Object field slightly weakens type clarity. Code length: Implementation is reasonably concise, with constructor delegation reducing duplication, although documentation and similar overloads add length. Action granularity: Several lines combine declarations, assignments, or statements with closing braces and documentation, making individual actions harder to scan. Reading flow: The overall member order is natural, but inconsistent spacing, long signatures, inline method bodies, and comments attached to preceding code interrupt reading.
Run 2
Code Structure: Fields, constructors, and accessors are logically grouped, with straightforward constructor delegation. Nesting: Minimal nesting makes control flow easy to follow. Clarity of intent: Descriptive names, explicit nullability, and useful Javadoc clearly explain the exception's purpose and stored information. Code length: Implementation is reasonably concise, although repeated constructor documentation and message construction add some verbosity. Action granularity: Multiple imports, field declarations, and assignments share lines, reducing scanability. Reading flow: Inconsistent spacing, long signatures, and comments or statements placed immediately after closing braces disrupt otherwise natural top-to-bottom reading. Overall, the logic is readily understandable, but compressed and inconsistent formatting noticeably weakens readability.
Run 3
Code Structure: Fields, constructors, and getters are logically organized, with sensible constructor delegation. Nesting: Minimal nesting makes control flow easy to follow. Clarity of intent: Descriptive names and thorough Javadoc clearly explain the exception and its metadata, though storing either a Class or String as Object adds some ambiguity. Code length: Implementation is concise; repeated constructor documentation adds length but remains useful. Action granularity: Multiple imports, field declarations, and assignments share lines, reducing scanability. Reading flow: Inconsistent spacing, long signatures, and closing braces joined to comments or return statements interrupt otherwise natural progression. Overall, clear semantics and simple structure are weakened by compressed, inconsistent formatting.