Question

If a run time error occurs when executing a PL/SQL procedure, what happens?​

Answer 1

$\bold\green{ANSWER}$

IF Such a problem arises the uplying runtime would stop displaying the outcome of the programme

Answer 2

PL/SQL run-time errors can arise from design faults, coding mistakes, hardware failures, and many other sources. You cannot anticipate all possible errors, but you can code exception handlers that allow your program to continue to operate in the presence of errors.

Guidelines for handeling PL/SQL

• Because reliability is crucial for database programs, use both error checking and exception handling to ensure your program can handle all possibilities:
• Add exception handlers whenever errors can occur.

• Errors are especially likely during arithmetic calculations, string manipulation, and database operations. Errors can also occur at other times, for example if a hardware failure with disk storage or memory causes a problem that has nothing to do with your code; but your code still must take corrective action.

• Add error-checking code whenever bad input data can cause an error.

• Expect that at some time, your code will be passed incorrect or null parameters, that your queries will return no rows or more rows than you expect.

• Test your code with different combinations of bad data to see what potential errors arise.

• Make your programs robust enough to work even if the database is not in the state you expect.
• For example, perhaps a table you query will have columns added or deleted, or their types changed. You can avoid such problems by declaring individual variables with %TYPE qualifiers, and declaring records to hold query results with %ROWTYPE qualifiers.

• Handle named exceptions whenever possible, instead of using WHEN OTHERS in exception handlers.

• Learn the names and causes of the predefined exceptions. If your database operations might cause particular ORA-n errors, associate names with these errors so you can write handlers for them. (You will learn how to do that later in this chapter.)

• Write out debugging information in your exception handlers.

• You might store such information in a separate table. If so, do it by invoking a subprogram declared with the PRAGMA AUTONOMOUS_TRANSACTION, so that you can commit your debugging information, even if you roll back the work that the main subprogram was doing.

• Carefully consider whether each exception handler should commit the transaction, roll it back, or let it continue.

• No matter how severe the error is, you want to leave the database in a consistent state and avoid storing any bad data.

I hope this is more than enough to help you

follow me for more quality answers ✌️