Discussions
Categories
- 197.1K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.7K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 555 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.3K SQL Developer
- 296.3K Development
- 17 Developer Projects
- 139 Programming Languages
- 293K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 158 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 466 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
Unchecked exceptions thrown by parsers

Why are exceptions thrown by parsers, such as parseInt, unchecked? It is not a programming error to try to parse text input containing errors or optional values that need not be present.
Answers
-
Why are exceptions thrown by parsers, such as parseInt, unchecked? It is not a programming error to try to parse text input containing errors or optional values that need not be present.
Same answer as in your other thread - only the person designing the code can answer 'why' questions about the choices they made.
(note - my using the 'only the developer ...' is NOT meant to discourage you from posting such questions - only trying to be inform you/others that it is a design decision and, as such, only the developer knows the real reason that decision was made).
An earlier doc section states this:
The third kind of exception is the runtime exception. These are exceptional conditions that are internal to the application, and that the application usually cannot anticipate or recover from.
And further classifies those as 'unchecked'.
Certainly the argument can be made that a problem parsing something can both be anticipated and recovered from so should raise a checked exception.
Although different people might argue differently in the forums ONLY the developer can tell you why any given choice was made. There could have been a legitimate reason or it could have been ignorance of best practices in writing exceptions and handlers as your other doc link discusses.