summaryrefslogtreecommitdiff
path: root/topics
diff options
context:
space:
mode:
authorArun Isaac2022-08-25 11:39:50 +0530
committerArun Isaac2022-08-25 11:39:50 +0530
commit574900c30dc5576d04c5306187df4fe2e1785ef0 (patch)
treedd3db13fd494712abf449c14879cb7dd55cfe92c /topics
parent033cc2228d9277c4dd42e8d9160b7d2966dc2bc7 (diff)
downloadgn-gemtext-574900c30dc5576d04c5306187df4fe2e1785ef0.tar.gz
Use exceptions to indicate errors.
Diffstat (limited to 'topics')
-rw-r--r--topics/use-exceptions-to-indicate-errors.gmi16
1 files changed, 16 insertions, 0 deletions
diff --git a/topics/use-exceptions-to-indicate-errors.gmi b/topics/use-exceptions-to-indicate-errors.gmi
new file mode 100644
index 0000000..e302dd3
--- /dev/null
+++ b/topics/use-exceptions-to-indicate-errors.gmi
@@ -0,0 +1,16 @@
+# Use exceptions to indicate errors
+
+Often, we indicate that a function has encountered an error by returning a None value. Here's why this is a bad idea and why you should use exceptions instead.
+
+When we return None values to indicate errors, we have to take care to check the return value of every function call and propagate errors higher and higher up the function call stack until we reach a point where the error is handled. This clutters up the code, and is one reason why writing correct code in languages like C that don't have exceptions is a pain.
+
+With exceptions, we only have to create an exception handler (try/except block in Python) at the highest level. Any exception raised by functions below that level are automatically passed on to the except block with no additional programmer effort.
+
+Here's an example where we run mapping, and if there's an error, we return an error page. Else, we return the results page. Notice that we do not check the return value template_vars.
+```
+try:
+ template_vars = run_mapping.RunMapping(start_vars, temp_uuid)
+ return render_template("mapping_results.html", **template_vars)
+except:
+ return render_template("mapping_error.html")
+```