Theory
Tuesday, 11:40 am: BookBridge मरता है
Return desk busy है। एक member एक book हाथ में देता है, librarian days kept की number type करती है, और finger की एक slip के साथ Enter दबाती है: "12x"।
Integer.parseInt("12x") उससे एक number नहीं बना सकता। Program एक red stack trace print करता है और exit हो जाता है। Queue stuck, unsaved records gone, और librarian अब आपके software पर distrust करती है।
Bad input, full crash। Java का mechanism ऐसे moments को उनसे मरने के बजाय survive करने का exception है।
Theory
Incident Report
एक well-run library में, desk पर एक problem building shut नहीं करती। Assistant एक incident report लिखता है (क्या हुआ, कहाँ) और इसे ऊपर pass करता है जब तक कोई authorised इसे handle न करे। सिर्फ़ तभी अगर कोई इसे न ले building असल में बंद होती है।
एक Java exception वह report है: एक object जो problem describe करता है, calling methods से ऊपर throw किया गया जब तक कोई handler इसे catch न करे। Top पर unhandled: program closed, stack trace printed।
Theory
Trouble का Family Tree
हर throwable चीज़ class Throwable से descend करती है, जो 2 में split होती है:
- Error: serious JVM-level failures (OutOfMemoryError, StackOverflowError)। Programs इन्हें handle करने की कोशिश नहीं करते।
- Exception: problems जो एक program HANDLE कर सकता है, वह branch जिसमें यह unit रहती है।
Exception के अंदर एक special subtree बैठता है, RuntimeException, और वह split (runtime बनाम बाकी) वह distinction बनाता है जो exams सबसे ज़्यादा पूछते हैं: unchecked बनाम checked।
At a glance
Checked बनाम Unchecked Exceptions
| Aspect | Checked | Unchecked (RuntimeException) |
|---|---|---|
| Compiler की Demand | इसे catch या throws से declare कीजिए, वरना compile नहीं | कोई demand नहीं; run time पर strike करता है |
| Typical Cause | बाहरी world: files, network, devices | Logic bugs: null, ग़लत index, ग़लत number |
| Examples | IOException, SQLException | NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException |
| BookBridge Case | Catalog file पढ़ना | parseInt("12x"), b.title जब b null है |
Quiz
इनमें से कौन सा एक UNCHECKED exception है?
- IOException
- NullPointerException
- SQLException
- कोई भी exception जो programmer Exception extend करके define करता है
Show the answer
NullPointerException
NullPointerException RuntimeException extend करता है, unchecked subtree: compiler कभी आपको इसे handle करने पर मजबूर नहीं करता, यह बस तब erupt होता है जब आपकी logic slip होती है। IOException और SQLException 2 textbook checked examples हैं; compiler ऐसे code को build करने से मना करता है जो इन्हें ignore करता है। Option D subtle trap है: Exception (RuntimeException नहीं) extend करना आपके exception को CHECKED बनाता है, जो exactly वह है जो BookBridge नीचे चाहता है।
Theory
जब Java के पास आपकी Problem के लिए कोई Word नहीं है
Java कोई OverdueException ship नहीं करता: "book 14 दिनों से ज़्यादा रखी गई" एक library rule है, Java rule नहीं। जब built-in vocabulary के पास एक domain problem के लिए कोई word न हो, आप एक define करते हैं:
class OverdueException extends Exception {
OverdueException(String message) {
super(message);
}
}
Exception extend कीजिए, super(message) से message parent तक pass कीजिए (this/super lesson action में), और callers बाद में इसे getMessage() से पढ़ते हैं।
Think first
Design Decision: कौन सा Parent?
आप इसके बजाय RuntimeException extend कर सकते थे, OverdueException को unchecked बनाते हुए। Tap करने से पहले: overdue-return जैसे एक rule को कौन सा parent extend करना चाहिए, और choice क्या बदलता है?
Show the answer
Exception (checked) extend कीजिए। Choice decide करता है compiler क्या enforce करता है: checked का मतलब है हर method जो एक overdue case raise कर सकता है इसे catch या declare करने के लिए FORCED है, तो कोई भी future teammate silently library policy ignore नहीं कर सकता। RuntimeException उन programming bugs के लिए है जिन्हें आप code में fix करते हैं, उन conditions के लिए नहीं जिनकी आप expect करते हैं और handle करनी चाहिए। Rule of thumb: expected business situations, checked; programmer mistakes, unchecked।
Watch out
दो Lines जिन्हें Students Mix Up करते हैं
Exception बनाम Error: "OutOfMemoryError एक exception है जिसे हमें catch करना चाहिए" लिखना marks दो बार खोता है; यह एक Error है, और programs को Errors बिल्कुल handle नहीं करने चाहिए।
Compile Time बनाम Run Time: checked exceptions compile time पर CHECKED होते हैं, पर वे फिर भी run time पर OCCUR होते हैं। Compiler verify करता है आपने handling लिखी है; यह Tuesday को file missing होने से नहीं रोक सकता।
Theory
Report लिखी जा चुकी है; इसे कौन File करता है?
अब आपके पास पूरा taxonomy है: Errors जिन्हें आप छोड़ देते हैं, unchecked exceptions जिन्हें आप logic fix करके prevent करते हैं, checked exceptions और आपका खुद का OverdueException जिसे आपको formally handle करना चाहिए। जो missing है वह handling की grammar है खुद: एक method report कैसे throw करता है, एक caller इसे कैसे catch करता है, और क्या हमेशा regardless run होता है। वह grammar (throw, throws, try, catch, finally) अगला lesson है, और यह Tuesday के crash को desk पर एक polite red message में बदल देता है।
Summary
Key takeaways
- एक exception एक runtime problem describe करने वाला object है, call chain से ऊपर pass किया गया जब तक caught न हो; uncaught, program stack trace से मर जाता है।
- Throwable Error (JVM-level, handle मत कीजिए) और Exception (इन्हें handle कीजिए) में split होता है।
- Checked exceptions (IOException) को compile time पर catch या declare करना चाहिए; unchecked (RuntimeException family) run time पर strike करते हैं।
- NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException: unchecked regulars।
- User-defined: class OverdueException extends Exception, constructor super(message) call करता है।
- Exception extend करना इसे checked बनाता है, हर caller को rule respect करने पर मजबूर करते हुए।
- Memory hook: एक exception एक incident report है, fire alarm नहीं।