3.4Error handling & debugging
The essentials in 30 seconds
- Three families of errors: compilation, runtime and functional — the last is the most dangerous because nothing signals it.
- QUAND EXCEPTION intercepts a runtime error; HFSQL return values are also tested rather than assuming a write succeeded.
- Debugging = reproduce, isolate, understand the real cause, fix then verify; on the user side, a clear message and logging.
Running mini-case — Yacine saves an order despite the outage
Yacine records an order for electrical equipment when the HFSQL server becomes unreachable. Without precautions, the application stops abruptly and the user loses their input. He wraps the write in QUAND EXCEPTION, tests the query's return and displays an understandable message: “Order not saved: server unavailable, check the network.” The technical detail goes to the log, not to the screen. Later, a wrong total appears on some orders: Yacine reproduces the case with the same lines, sets a breakpoint before the calculation, steps through it and discovers a line with no price. He notes the reflex: intercept, test, log, then reproduce and isolate before fixing.
Self-contained case for this section: it returns in the course, diagram, script and 48h challenge of section 3.4.
1. Three families of errors
Robust code never assumes everything will go well. A compilation error is detected before execution: syntax mistake, unknown name. A runtime error occurs during operation: division by zero, missing file, network down, insufficient rights. A functional error is the most dangerous: the program runs but the result is wrong, and nothing signals it. An incorrect total in one of Yacine's invoices belongs to this family.
2. Intercept and test
WLangage offers QUAND EXCEPTION to intercept a runtime error and take back control instead of letting the application crash. But interception does not replace checking: an HFSQL write can fail because of a duplicate, a constraint or a lock. Yacine tests the return values of functions, plans a fallback behaviour and displays an understandable message — never a raw technical code. The detail goes to the log for diagnosis.
3. A debugging method
The integrated debugger offers breakpoints, step-by-step execution, variable inspection and the call stack. The method matters as much as the tool: reproduce the problem reliably, isolate the scope, understand the real cause rather than the symptom, then fix and verify the absence of regression. A bug you cannot reproduce cannot be fixed with certainty.
🔎 Concrete example — 🔎 Concrete example — Intercept, log, understand
Yacine secures the recording of an order then tracks down a wrong total:
QUAND EXCEPTION DANS
HExecuteRequete(Req_AjoutCommande)
SI HEnDehors(Req_AjoutCommande) ALORS
Erreur("La commande n'a pas pu etre enregistree.")
FIN
FAIRE
JournalAjoute("Erreur HFSQL commande", ErreurInfo())
Info("Serveur indisponible : reessayez ou contactez le support.")
FIN
// Debugging: breakpoint before the calculation, then step by step
nTotal = CalculeTotalLignes(TAB_Lignes)Reading: the user receives an action to take, the log keeps the technical detail.
Lesson: the breakpoint and stepping show where the value becomes wrong.
Section vocabulary
- Runtime error
- Error occurring during operation: missing file, network down, division by zero.
Simple example: Yacine's HFSQL query fails because the server is unavailable.
What it is not: a syntax mistake signalled before execution.
Reflex: crash during the action → runtime error.
- QUAND EXCEPTION
- WLangage mechanism that intercepts a runtime error to handle it cleanly.
Simple example: Yacine uses it around the order write.
What it is not: letting the application stop abruptly in front of the user.
Reflex: take back control → QUAND EXCEPTION.
- Functional error
- Situation where the program runs correctly but produces a wrong result.
Simple example: An invoice total is wrong because of a line with no price.
What it is not: an exception that visibly interrupts processing.
Reflex: wrong result without a crash → functional error.
- Breakpoint
- Marker placed in the code to suspend execution and inspect the state at that point.
Simple example: Yacine sets it before CalculeTotalLignes.
What it is not: a simple trace displayed after the end of processing.
Reflex: observe a suspect area → breakpoint.
- Logging
- Recording errors and technical events to diagnose afterwards.
Simple example: Yacine records the HFSQL error in the log without displaying it on screen.
What it is not: a raw technical message shown directly to the user.
Reflex: diagnose remotely → log.
In practice — In practice — Making your code robust and debugging
- Wrap risky operations (file, network, conversion, calculation) and test HFSQL return values, like Yacine.
- Set a breakpoint before the suspect area, step through and inspect the variables.
- Apply the method: reproduce, isolate, understand the real cause, fix then verify.
- Replace technical messages with an understandable message and log the detail for diagnosis.
Step-by-step script — track down a wrong total like Yacine (4 min)
1) Reproduce the problem with the same data and the same actions. 2) Set a breakpoint before the suspect calculation and step through. 3) Inspect the variables: spot the line whose price is empty or badly converted. 4) Fix the real cause, not the symptom. 5) Verify the corrected case and the absence of regression on the other orders.
Keep this reflex: a bug that cannot be reproduced cannot be fixed with certainty.
Copy-paste template — Yacine's errors & debugging sheet
Errors : compilation / runtime / functional (the most dangerous)
Intercept : QUAND EXCEPTION + test HFSQL return values
User : understandable message; technical detail in the log
Method : reproduce -> isolate -> understand -> fix -> verify
Tools : breakpoint, step by step, variables, call stack, traceAn unreachable server
Yacine intercepts the error, logs it and invites the user to try again.
A wrong total
Yacine reproduces, isolates the line with no price and fixes the real cause.
A raw message
Yacine replaces “Error 0x8004” with a clear and actionable message.
An intermittent bug
Yacine looks for what varies (volume, workstation, rights) to reproduce it reliably.
✓ Best practices
- Always test the return values of risky operations.
- Reproduce before fixing.
- Display a clear message, log the detail.
✗ Common pitfalls
- Assuming that an HFSQL write succeeded.
- Fixing the symptom without the cause.
- Showing a raw technical code to the user.
Key takeaways
- Compilation, runtime and functional: three families with different consequences.
- QUAND EXCEPTION intercepts; HFSQL return values are tested.
- Debugging = reproduce, isolate, understand, fix, verify.
- Understandable user message and logging of the technical detail.
48h challenge — apply it tomorrow
Like Yacine, wrap a risky operation of your application (HFSQL write, file read, conversion) in QUAND EXCEPTION, test its return and log the detail. Display an understandable message. Then take a real bug: reproduce it, set a breakpoint, step through and note in one sentence the real cause you found.
- I distinguish compilation, runtime and functional errors.
- I know how to intercept an error and test an HFSQL return value.
- I apply a four-step debugging method.
Frequently asked questions
How do you handle an error without crashing the application?
By anticipating risky operations: file access, network, database, conversions. Wrap them with QUAND EXCEPTION, test return values, plan a fallback behaviour and log the technical detail. The user must receive an understandable and actionable message, never a raw technical code. For several related writes, a transaction avoids an inconsistent state.
What is the best method to find the origin of a bug?
Reproduce reliably, isolate the scope, understand the real cause, then fix and verify the absence of regression. The debugger — breakpoint, stepping, variable inspection — supports this method, it does not replace it. A bug you cannot reproduce cannot be fixed with certainty: always start with the exact conditions.
What is the QUAND EXCEPTION mechanism for?