Let’s make a metaphor for how programs work.
Imagine a person at a desk. They have an “in” box, and an “out” box.
Some other workers put folders in the “in” box. Their job is to take the folder out and open it up. The folder contains pieces of paper with math problems on them. The person solves each math problem, and when they solve all of them, they close the folder and put it in the “out” box.
Now imagine some papers have weird things like, “Use the answer to problem 3 on the last page for this value.” This is a little more complicated but we can imagine the person handling it.
Some folders have other folders inside. So when that happens they do the math on all the papers before the “inner” folder, then open the “inner” folder. They treat it like the “outer” folder: they do the math on the papers inside, then close the folder. Then they do the math on the rest of the papers in the “inner” folder.
Now imagine a folder with folders that have folders with folders in them. That’s a good way to describe a complicated program. But we can follow the simple steps above to imagine the person slowly working through all of the math papers in sequence and understand how the person works through it.
Now let’s add exception handling.
The “try/catch” part of the program structure is like if the page before a folder has a special instruction:
> If any of the problems in the upcoming folder cannot be solved, please do these steps…
The “throw” part of the program structure is like a math problem has these special instructions:
> If box 3 on the last page is zero, this problem is unsolvable.
So what happens when the person gets to that instruction is they stop and say, “Oh.” They cannot continue because they cannot solve any more problems. So they close this “inner” folder.
Then they move backwards and look at the piece of paper from before the folderr. They see, “If any of the problems in the upcoming folder…” and say, “Ah, here we go.” Now they do the steps. When they finish, that’s it for this stack of papers. They close the folder they are in, move it out of the way, then proceed with the next papers.
This can go very far back. They might be 10 folder layers deep. They will still dutifully work backwards, inspecting papers and closing folders until they find, “If anything ahead cannot be solved…”. If they cannot find instructions like that before they close the final “outer” folder, then that set of problems is unsolvable. They stamp it “TERMINATED” and put it in their “out” box.
—
Inside the code that compilers generate, they do things like this. When code enters a try/catch, a little bit of information about that gets stored in memory. As code calls different parts of itself, it leaves little bits of data in memory about how it got to where it is.
When something throws an exception, it changes how the program works. It stops moving forwards and starts moving backwards. It follows the trail of breadcrumbs describing how it got to where it is, and at each marker it asks, “Is there a catch block I can go to here?” If not, it keeps working backwards. If it reaches the end of the trail before it finds a catch block, the program ends.
Latest Answers