One idea
Generics stop wrong data from entering your collections. Exceptions make failure visible and controlled.
In your recruiter CLI, use both together: typed data in, clear error out.
Why generics matter
A recruiter app will hold candidates, jobs, skills, and match scores. If you use raw List or Map, Java cannot protect you from mixing them up.
Prefer List, Map, and Optional style types. The compiler then catches mistakes before your friend tries to run the repo.
Typed collections
This is better than putting everything into one ArrayList. The method says exactly what it accepts and returns.
import java.util.ArrayList;
import java.util.List;
public class CandidateStore {
private final List<Candidate> candidates = new ArrayList<>();
public void add(Candidate candidate) {
candidates.add(candidate);
}
public List<Candidate> findBySkill(String skill) {
List<Candidate> result = new ArrayList<>();
for (Candidate candidate : candidates) {
if (candidate.skills().contains(skill)) {
result.add(candidate);
}
}
return result;
}
}Use custom exceptions
A bad email, missing name, or invalid experience should not crash your app with a random NullPointerException. Create a small exception that explains the problem.
Use checked exceptions when the caller should deal with the error. Use unchecked exceptions for programmer mistakes. For input data from users or files, a checked exception is often clearer.
Validate candidate data
This example rejects bad data early. The calling code must decide what to show to the user.
public class InvalidCandidateException extends Exception {
public InvalidCandidateException(String message) {
super(message);
}
}
public record Candidate(String name, String email, int experienceYears, List<String> skills) {
public Candidate {
if (name == null || name.isBlank()) {
throw new IllegalArgumentException("Candidate name is required");
}
if (email == null || !email.contains("@")) {
throw new IllegalArgumentException("Candidate email is invalid");
}
if (experienceYears < 0) {
throw new IllegalArgumentException("Experience cannot be negative");
}
}
}Do not swallow errors
Beginners often write catch blocks that print nothing or only say "error". That makes debugging painful during a hackathon demo.
Show a short user-friendly message. Keep the original message useful for fixing the issue.
try {
Candidate candidate = parser.parseCandidate(inputLine);
store.add(candidate);
} catch (InvalidCandidateException e) {
System.out.println("Skipped candidate: " + e.getMessage());
}Ask AI carefully
You can ask ChatGPT or Gemini to review your exception design. Paste only the relevant class, not private data.
Check that the AI does not suggest raw List, broad catch (Exception e), or System.exit inside business classes. Your app should handle errors near the CLI layer.
Prompt:
Review this Java CLI class. Suggest better generics and exception handling.
Do not rewrite the whole app. Point out raw types, broad catches, and unclear error messages.Do this now
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done