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() {
{
int morningTemperature = 18;
int eveningTemperature = 14;
int lowerTemperature = morningTemperature;
if (eveningTemperature < lowerTemperature) {
lowerTemperature = eveningTemperature;
}
}
return this.identifier;
}
}
Run 1
The code starts as a well-structured exception class with clear Javadoc, logical constructors, and sensible field usage. However, readability is severely damaged by a stray, unrelated temperature-comparison code block inserted inside the getIdentifier() method. This breaks action granularity, reading flow, and clarity of intent. Additionally, the getIdentifier() method has unnecessary extra blank lines and braces. Nesting is mostly flat, and method lengths are reasonable, but the inclusion of irrelevant logic makes the overall purpose ambiguous and confusing. Fixing that section would significantly improve the score.
Run 2
The code is generally well-structured for readability, featuring clear naming, thorough Javadoc, and flat methods with low nesting. However, it contains a critical, confusing block of unrelated code inside getIdentifier(), severely breaking logical organization and reading flow. This stray code defines temperature variables and an if-statement, completely disconnected from the exception's purpose, making the method ambiguous. While constructors are clear and documentation is strong, this insertion means the code fails to maintain clear intent throughout. The rest of the class is concise and appropriately granular, with one action per line mostly, but the erroneous block undermines overall readability.
Run 3
The code is generally well-structured with logical organization, clear Javadoc comments, and sensible constructor overloading typical of a Spring exception class. However, there is a critical readability issue: an extraneous block of unrelated temperature variable code appears inside the getIdentifier() method before the return statement, making the purpose ambiguous and the reading flow disorganized. Apart from this, the code is flat, uses one action per line, and is fairly concise. The intrusion of the unrelated code significantly lowers the overall score despite the otherwise clean implementation.
Run 1
Code Structure: Fields, constructors, and getters are logically organized, but an unrelated temperature-calculation block disrupts getIdentifier(). Nesting: Mostly flat, with only shallow conditionals; the unnecessary block adds avoidable nesting. Clarity of intent: Descriptive names, documentation, and nullability annotations clearly explain the exception API, while the unused temperature calculation creates confusion. Code length: Constructor delegation keeps implementation concise, though repeated documentation and the irrelevant block add length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Consistent formatting and predictable member ordering support natural reading until the poorly integrated temperature block abruptly interrupts the getter.
Run 2
Code Structure: Fields, constructors, and accessors are logically grouped, but an unrelated temperature-calculation block disrupts getIdentifier(). Nesting: Mostly flat; the extra block and its conditional add modest, unnecessary nesting. Clarity of intent: Descriptive names, Javadoc, and nullability annotations clarify the exception's purpose, but the unused temperature calculation is confusing and unrelated. Code length: Constructor delegation keeps implementation concise, although repeated documentation, similar overloads, and the extraneous block add length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Consistent formatting and conventional member ordering support natural reading until the abruptly inserted, inconsistently indented temperature block breaks the flow.
Run 3
Code Structure: Fields, constructors, and getters are logically organized, but an unrelated temperature-calculation block disrupts getIdentifier(). Nesting: Generally shallow; the extra block and conditional add unnecessary nesting. Clarity of intent: Descriptive names, documentation, and nullability annotations make the exception's purpose clear, while the unused temperature calculation is confusing. Code length: Reasonably concise for the supported constructor overloads, though repeated documentation and message construction add some verbosity, and the unrelated block is unnecessary. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Consistent ordering and constructor delegation create a natural flow, but the temperature block's inconsistent indentation and irrelevant logic sharply interrupt it.