# Checked vs. Unchecked Exceptions in Java: A Historical Perspective and Comparison

DevFeed: [Checked vs. Unchecked Exceptions in Java: A Historical Perspective and Comparison](<https://devfeed.tech/articles/checked-vs-unchecked-exceptions-in-java-why-it-s-so-confusing-24997.md>)

Original publisher: [Read original article](<https://codeahoy.com/java/2016/04/02/checked-vs-unchecked-exceptions-in-java/>)

Author: umer

Published: 2016-04-02T00:00:00Z

Content type: tutorial

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Exception](<https://devfeed.tech/topics/exception.md>), [Java](<https://devfeed.tech/topics/java.md>), [Error Handling](<https://devfeed.tech/topics/error-handling.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [C](<https://devfeed.tech/topics/c.md>), [Lisp](<https://devfeed.tech/topics/lisp.md>)

Tags: [c](<https://devfeed.tech/tags/c.md>), [error-handling](<https://devfeed.tech/tags/error-handling.md>), [exception-handling](<https://devfeed.tech/tags/exception-handling.md>), [exceptions](<https://devfeed.tech/tags/exceptions.md>), [java](<https://devfeed.tech/tags/java.md>), [lisp](<https://devfeed.tech/tags/lisp.md>)

## AI overview

A tutorial for new Java developers that explains the historical motivation for Java's exception-handling mechanism and examines the debate between checked and unchecked exceptions, contrasting them with error-code patterns in C.

## Source excerpt

This blog post is intended for new Java developers. It starts with a historical perspective and a look at what motivated the design and creation of Java's exception handling mechanism. It also explores the hotly debated checked vs unchecked exceptions debate with some personal insights. Let's start. Historical Perspective Back in the time of the "C" programming language, it was customary to return values such as -1 or NULL from functions to indicate errors. This was practical for small applications but didn't scale well for larger applications - developers had to check and track every possible return value: a return value of 2 might indicate "host is down" error in library A whereas in library B, it could mean "illegal filename". Although, developers tried to fix this and attempts were made to standardize error codes by setting global variables, but it didn't help much. #define ENOENT 2 /* No such file or directory */ #define ESRCH 3 /* No such process */ #define EINTR 4 /* Interrupted system call */ #define EIO 5 /* I/O error */ #define ENXIO 6 /* No such device or address */ #define E2BIG 7 /* Argument list too long */ #define ENOEXEC 8 /* Exec format error */ #define EBADF 9 /* Bad file number */ #define ECHILD 10 /* No child processes */ #define EAGAIN 11 /* Try again */ #define ENOMEM 12 /* Out of memory */ James Gosling and other designers felt that a similar approach would go against the design goals of Java programming language. They wanted: a cleaner, robust and portable approach built-in language support for error checking and handling. Essentially, one of their main design goals was to build a language that's robust and able to cope with errors during execution or at least recognize when going go wrong. This principle is at the core of Java's error handling design, as we'll see later. James Gosling explains in one of his interviews: One of the traditional things to screw up in C code is opening a data file to read. It's semi-traditional in the C world to