例外処理

The check that cannot be written

• A program opens a file. Before opening it, you could check that the file exists, that it is readable, that the disk is present. Suppose every check passes.
• Between the last check and the open, a user pulls out the USB stick. The file existed when you asked and does not exist when you open it, and no amount of checking in advance could have closed that gap.
• Some errors are simply not preventable, because the world changes between the test and the action. What a program can do is respond to them when they happen.
• This lesson is the exception 异常, the TRY structure that handles one, and where in a program an exception should be caught.

What an exception is and why handle it

• An exception is an error that occurs during execution: division by zero, a file not found, invalid input, a network that has gone away.
• Exception handling 异常处理 lets the program detect the error and respond in a controlled way, instead of crashing and losing the user's work.
• Real programs face errors that cannot be prevented in advance, as the hook shows. And without exceptions, every single operation would need its own IF check around it, burying the actual algorithm in error tests.
• The third benefit is the one the exam most often asks for: it separates the normal flow from the error handling, so the main path reads cleanly.

The TRY structure

TRY
    OPENFILE "data.txt" FOR READ
    READFILE "data.txt", line
    CLOSEFILE "data.txt"
EXCEPT FileNotFound
    OUTPUT "Sorry, the file does not exist."
EXCEPT ReadError
    OUTPUT "Sorry, there was an error reading the file."
FINALLY
    OUTPUT "Finished attempting to read."
ENDTRY

• The TRY block holds the code that might fail. If it runs without error, the EXCEPT blocks are skipped entirely.
• If an exception occurs, execution jumps immediately to the first matching EXCEPT block. The rest of the TRY block does not run.
• A FINALLY block runs whether or not an exception happened, which makes it the right place for cleanup such as closing a file.

One path when all is well, another when it is not, and one that always runs

Worked example: trace the flow

Raising an exception

• A subroutine that detects a problem it cannot sensibly deal with can raise 抛出 an exception, passing responsibility to whoever called it:

IF b = 0 THEN RAISE DivideByZero

• This is the right design when the subroutine knows something is wrong but not what should be done about it. A division routine knows the divisor is zero; only the caller knows whether to ask the user again, use a default, or abandon the calculation.

Where to handle it

• Handle an exception close to where it occurs when the response is simple and local: print a message, use a default, ask the user to try again.
• Handle it higher up when the decision belongs to a larger part of the program: whether to abandon a whole transaction, roll back a change, or tell the user the operation failed.
• The rule of thumb: catch it at the level that has enough information to decide what to do, not at the level that first notices.

Worked example: what not to do

Marks that slip away

You've got it