Theory
Tuesday, 11:40 am: BookBridge dies
return desk busy છે. member book hand over કરે છે, librarian kept days ની number type કરે છે, અને finger ની slip સાથે Enter hit કરે છે: "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 કરવાની, એમાંથી die થવાને બદલે, એ exception છે.
Theory
incident report
well-run library માં, desk પર problem building ને shut નથી કરતી. assistant incident report લખે છે (શું થયું, ક્યાં) અને એને upward pass કરે છે જ્યાં સુધી કોઈ authorised એને handle ન કરે. જો કોઈ એને take ન કરે તો જ building actually close થાય છે.
Java exception એ report છે: object જે problem ને describe કરે છે, calling methods માંથી up thrown થાય છે જ્યાં સુધી કોઈ handler એને catch ન કરે. top પર unhandled: program closed, stack trace printed.
Theory
trouble ની family tree
દરેક throwable thing class Throwable થી descend થાય છે, જે 2 માં split થાય છે:
- Error: serious JVM-level failures (OutOfMemoryError, StackOverflowError). programs એ handle કરવાનો પ્રયાસ નથી કરતા.
- Exception: problems જે program handle કરી શકે છે, જે branch માં આ unit lives કરે છે.
Exception ની અંદર એક special subtree બેસે છે, RuntimeException, અને એ split (runtime vs બાકીના) એ distinction create કરે છે જે exams most ask કરે છે: unchecked vs checked.
At a glance
Checked vs unchecked exceptions
| Aspect | Checked | Unchecked (RuntimeException) |
|---|---|---|
| Compiler ની demand | Catch it અથવા throws સાથે declare it, અથવા no compile | No demand; run time પર strikes |
| Typical cause | Outside world: files, network, devices | Logic bugs: null, bad index, bad number |
| Examples | IOException, SQLException | NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException |
| BookBridge case | catalog file ને read કરવું | 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 કરવા force નથી કરતો, એ simply erupt થાય છે જ્યારે તમારું logic slip થાય છે. IOException અને SQLException એ 2 textbook checked examples છે; compiler એ code ને build કરવા refuse કરે છે જે એને ignore કરે છે. Option D એ subtle trap છે: Exception (RuntimeException નહીં) ને extend કરવાથી તમારું exception CHECKED બને છે, જે exactly છે જે BookBridge નીચે wants છે.
Theory
જ્યારે Java ની પાસે તમારા problem માટે કોઈ word નથી
Java OverdueException ship નથી કરતું: "book kept beyond 14 days" એ library rule છે, Java rule નહીં. જ્યારે built-in vocabulary ની પાસે domain problem માટે કોઈ word નથી, તમે એક define કરો છો:
class OverdueException extends Exception {
OverdueException(String message) {
super(message);
}
}
Exception ને extend કરો, message ને parent તરફ super(message) સાથે pass કરો (this/super lesson at work), અને callers પછી getMessage() દ્વારા એને read કરે છે.
Think first
Design decision: કયો parent?
તમે OverdueException ને unchecked બનાવવા માટે RuntimeException ને પણ extend કરી શકો છો. tap કરતા પહેલા: overdue-return જેવી rule કયા parent ને extend કરવી જોઈએ, અને choice શું change કરે છે?
Show the answer
Exception (checked) ને extend કરો. choice decide કરે છે કે compiler શું enforce કરે છે: checked એટલે દરેક method જે overdue case ને raise કરી શકે છે એ FORCED છે કે catch કરે અથવા declare કરે, એટલે કોઈ future teammate library policy ને silently 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 vs Error: લખવું "OutOfMemoryError એ exception છે જે આપણે catch કરવી જોઈએ" twice marks lose કરે છે; એ Error છે, અને programs Errors ને handle કરવા માટે meant નથી.
Compile time vs run time: checked exceptions compile time પર CHECKED થાય છે, પણ તેઓ હજુ OCCUR run time પર થાય છે. compiler verify કરે છે કે તમે handling લખ્યું છે; એ Tuesday પર file ને missing થવાથી prevent નથી કરી શકતું.
Theory
report લખાયેલું છે; કોણ file કરે છે?
હવે તમારી પાસે આખી taxonomy છે: Errors જે તમે alone leave કરો છો, unchecked exceptions જે તમે logic ને fix કરીને prevent કરો છો, checked exceptions અને તમારી પોતાની OverdueException જે તમારે formally handle કરવી જોઈએ. શું missing છે એ handling ની grammar itself છે: method કેવી રીતે report ને throws કરે છે, caller કેવી રીતે એને catch કરે છે, અને શું always runs regardless. એ grammar (throw, throws, try, catch, finally) next lesson છે, અને એ Tuesday ના crash ને desk પર polite red message માં ફેરવે છે.
Summary
Key takeaways
- Exception એ runtime problem ને describe કરતું object છે, call chain માં up passed થાય છે જ્યાં સુધી caught; uncaught, program stack trace સાથે dies.
- 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 કરવા force કરે છે.
- Memory hook: exception એ incident report છે, fire alarm નહીં.