Per the text, exception handling is needed to ensure that programs catch potenti
ID: 3835887 • Letter: P
Question
Per the text, exception handling is needed to ensure that programs catch potential problems, be they system problems or input problems. Some programmers prefer to throw distinct types of exceptions for each error. Other programmers believe that having so many catch blocks is unappealing and code only generic catching. Provide one (1) scenario where generic error handling is a good idea and one (1) scenario where such a practice falls short of expectations.
Determine whether or not there is a point beyond which a program might be “catching” too many exceptions during exception handling. If you support the practice, suggest the key issues that determine the amount of exception handling to include within a program. If you oppose the practice, justify your response.
Explanation / Answer
Scenario 1: If you want to catch the exceptions in an application, where in if not caught, error will be shown to user and will impact user experience, there we should/can use generic exception handling.
This too should be done at top level.
e.g., No software should throw an exception to user stating out of memory error.
Scenario 2: No need to catch all exceptions in a library because it may mask problems that have nothing to do with library, like "OutOfMemoryException" which should be bubbled up so that the user can be notified
Generic exception handling is a bad practice. Per me, catch only those exceptions that you can properly handle yourself. If you cannot handle the exception completely then you should let it bubble up to someone who can.
Or I prefer going with a hybrid approach in case of UI based applications, handle all the exceptions that are expected to happen, e.g., IO errors, network errors, out-of-memory errors, missing-code errors, null-pointer-dereferencing and at the end, at the top layer add the generic exception handling and log the error.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.