Why use 'try' ' catch' 'finally' to handle exception

The teacher said that using exception testing can improve the robustness of the program. Clearly it is true.

But there is a paradox here.

If I didn't realize that this section of the program may have exception. I wouldn't use try{} either!
If I realize that this program may be has exception, why don't I fix this program to make it more robust?

For example，simple function

function c=div(a,b)
 c=a/b;
end

If b=null or b=0 or b is char ，there will be an exception, why do I have to use

function c=div(a,b)
try{c=a/b;
   }
catch (children class){…………
                   } 
catch(parent class){…………
                }
catch(exception e){…………
               }        
end

Why do not I use a switch case + @NotEmpty @NotNull isDigit() to verify that the input parameters？

If you find that the bucket is leaking

try catch helps you pour the leaked water back into the bucket

But why don't I plug the bucket hole?

If you don't notice the bucket is leaking

try catch doesn't help much either

this is my confusion

It's not about knowing or not knowing in advance that you program may throw an exception in some particular code block. It's about being able to recover if "something" happens. For example, if the error causes your application to crash, it results in negative consequences:

1. Some opened resources may not get closed properly (depends on OS and a bunch of other factors).
2. User experience is bad: people don't like seing fatal crashes of the apps they are using.

However, if you wrap your logic in a try-catch block, you are able to recover from getting an error (not always, of course, - depends on the error).

Then you may ask: "Why not just wrap the whole program in an uber-try-catch block"? Well, you can. But the things is that most of the time "recovery" depends on two things:

1. What type of error did happen?
2. Where exactly did it happen?

Depending on the answers, you will try to restore the app flow one way or another, which would be problematic - if not impossible - if you just had an ultimate try-catch wrapping your whole app.

Your follow-up question may be: "But then, how do I decide on the granularity of my try-catches"? How many of them should I have across my codebase? How frequently should I insert them? Should I wrap every single line into its own try-catch? Or it is fine to have it per function/method?

Well, these are good questions, because there's no silver bullet here. It really depends on your code and on the specific programming language you are using. For example, some PLs (like Java) have so-called "checked exceptions": if some function defines a checked exception, then you must catch it when you call this function (or later, at some point, upper in the call stack). Some languages don't have this concept. Also, keep in mind different paradigms: procedural programming, functional programming, OOP, etc. All of this impacts your strategy of handling exceptions. As a rule of thumb, you may follow a recommendation that whenever you open some resource (file, DB connection, etc.) - wrap it in try-catch-finally and make sure to close this resource in the finally block. Some languages (like Java) even have a special syntax for this, called try-with-resources.