Error handling in procedures in MySQL - Time & Space Complexity
When we use error handling in MySQL procedures, we want to know how the time to run changes as the data grows.
We ask: How does adding error checks affect the speed when the procedure runs on more data?
Analyze the time complexity of the following code snippet.
CREATE PROCEDURE update_stock()
BEGIN
DECLARE done INT DEFAULT FALSE;
DECLARE v_product_id INT;
DECLARE cur CURSOR FOR SELECT id FROM products;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
OPEN cur;
read_loop: LOOP
FETCH cur INTO v_product_id;
IF done THEN
LEAVE read_loop;
END IF;
UPDATE inventory SET quantity = quantity - 1 WHERE product_id = v_product_id;
END LOOP;
CLOSE cur;
END;
This procedure loops through all products and updates inventory, using error handling to detect the end of the cursor.
- Primary operation: Looping through each product with a cursor.
- How many times: Once for each product in the products table.
As the number of products grows, the procedure runs the update for each one, plus checks for the end of the cursor each time.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 updates and cursor fetch checks |
| 100 | About 100 updates and cursor fetch checks |
| 1000 | About 1000 updates and cursor fetch checks |
Pattern observation: The work grows directly with the number of products; more products mean more updates and cursor fetch checks.
Time Complexity: O(n)
This means the time to run grows in a straight line with the number of products processed.
[X] Wrong: "Adding error handling makes the procedure run much slower, like squared time."
[OK] Correct: Error handling here only adds a small check each loop, so it grows linearly, not much slower.
Understanding how error handling affects procedure speed helps you write reliable code that scales well, a useful skill in real projects.
"What if we added nested loops inside the procedure? How would the time complexity change?"
Practice
DECLARE HANDLER in a MySQL stored procedure?Solution
Step 1: Understand the role of DECLARE HANDLER
DECLARE HANDLER is used to define actions when certain conditions or errors occur during procedure execution.Step 2: Identify the purpose in error handling
It helps catch errors and decide whether to continue or exit, preventing crashes and allowing custom responses.Final Answer:
To catch and handle errors during procedure execution -> Option BQuick Check:
Error handling = DECLARE HANDLER usage [OK]
- Confusing DECLARE HANDLER with variable declaration
- Thinking it creates tables or indexes
- Assuming it optimizes queries automatically
Solution
Step 1: Recall correct DECLARE HANDLER syntax
The syntax is: DECLARE [CONTINUE|EXIT] HANDLER FOR condition statement;Step 2: Match syntax with options
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN ... END; correctly uses DECLARE CONTINUE HANDLER FOR SQLEXCEPTION followed by a statement block.Final Answer:
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN ... END; -> Option AQuick Check:
Correct syntax = DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN ... END; [OK]
- Placing CONTINUE after HANDLER incorrectly
- Omitting BEGIN...END block for multiple statements
- Wrong order of keywords
DECLARE EXIT HANDLER FOR SQLEXCEPTION SET @error_flag = 1;
SET @error_flag = 0;
INSERT INTO users(id, name) VALUES(1, 'Alice');
INSERT INTO users(id, name) VALUES(1, 'Bob');
Assuming
id is a primary key, what will be the value of @error_flag after execution?Solution
Step 1: Analyze the inserts and handler
The first insert succeeds. The second insert violates primary key (duplicate id), causing an SQLEXCEPTION.Step 2: Understand EXIT HANDLER effect
The EXIT HANDLER sets @error_flag = 1 and stops further execution.Final Answer:
1 -> Option AQuick Check:
Duplicate key error triggers EXIT HANDLER = 1 [OK]
- Assuming @error_flag stays 0 despite error
- Thinking procedure continues after EXIT HANDLER
- Confusing CONTINUE and EXIT handlers
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
DECLARE done BOOLEAN DEFAULT FALSE;
WHILE done = FALSE DO
-- some code
END WHILE;
Solution
Step 1: Check declaration order rules
In MySQL procedures, variables must be declared before handlers.Step 2: Identify declaration order in snippet
The handler is declared before the variable 'done', which is invalid.Final Answer:
Handler declared before variable 'done' is declared -> Option DQuick Check:
Variables before handlers = correct order [OK]
- Declaring handlers before variables
- Confusing NOT FOUND condition usage
- Ignoring declaration order rules
Solution
Step 1: Understand the goal
Insert user; if duplicate key error occurs, update existing user's name instead.Step 2: Choose handler type
CONTINUE HANDLER allows procedure to continue after catching duplicate key error and run UPDATE.Step 3: Evaluate other options
EXIT HANDLER stops execution, NOT FOUND is unrelated, and no handler defers error handling outside procedure.Final Answer:
Use DECLARE CONTINUE HANDLER for duplicate key error to run UPDATE statement -> Option CQuick Check:
CONTINUE HANDLER for duplicate key = update fallback [OK]
- Using EXIT HANDLER which stops procedure
- Using NOT FOUND for duplicate key errors
- Ignoring error handling inside procedure
Ready to prove it?
Pass the test and this pattern moves unknown
