From 6bab1a95cbe98921efd01dc1e0e8f956242238f4 Mon Sep 17 00:00:00 2001 From: Arjun Biddanda Date: Tue, 8 Nov 2016 11:28:28 -0600 Subject: [PATCH 1/3] added section to clarify exceptions vs assertions --- 03-exceptions.html | 64 +++++++++++++++++++++++++++------------------- 03-exceptions.md | 10 ++++++++ 2 files changed, 47 insertions(+), 27 deletions(-) diff --git a/03-exceptions.html b/03-exceptions.html index b5042e9..6767f34 100644 --- a/03-exceptions.html +++ b/03-exceptions.html @@ -30,48 +30,49 @@

Exceptions

-

Learning Objectives

+

Learning Objectives

  • Understand that exceptions are effectively specialized runtime tests
  • Learn when to use exceptions and what exceptions are available
    • +
  • Recognize the differences between exceptions and assertions

Exceptions are more sophisticated than assertions. They are the standard error messaging system in most modern programming languages. Fundamentally, when an error is encountered, an informative exception is ‘thrown’ or ‘raised’.

For example, instead of the assertion in the case before, an exception can be used.

-
def mean(num_list):
-    if len(num_list) == 0 :
-      raise Exception("The algebraic mean of an empty list is undefined. Please provide a list of numbers")
-    else :
-      return sum(num_list)/len(num_list)
+
def mean(num_list):
+    if len(num_list) == 0 :
+      raise Exception("The algebraic mean of an empty list is undefined. Please provide a list of numbers")
+    else :
+      return sum(num_list)/len(num_list)

Once an exception is raised, it will be passed upward in the program scope. An exception be used to trigger additional error messages or an alternative behavior. rather than immediately halting code execution, the exception can be ‘caught’ upstream with a try-except block. When wrapped in a try-except block, the exception can be intercepted before it reaches global scope and halts execution.

To add information or replace the message before it is passed upstream, the try-catch block can be used to catch-and-reraise the exception:

-
def mean(num_list):
-    try:
-        return sum(num_list)/len(num_list)
-    except ZeroDivisionError as detail :
-        msg = "The algebraic mean of an empty list is undefined. Please provide a list of numbers."
-        raise ZeroDivisionError(detail.__str__() + "\n" +  msg)
+
def mean(num_list):
+    try:
+        return sum(num_list)/len(num_list)
+    except ZeroDivisionError as detail :
+        msg = "The algebraic mean of an empty list is undefined. Please provide a list of numbers."
+        raise ZeroDivisionError(detail.__str__() + "\n" +  msg)

Alternatively, the exception can simply be handled intelligently. If an alternative behavior is preferred, the exception can be disregarded and a responsive behavior can be implemented like so:

-
def mean(num_list):
-    try:
-        return sum(num_list)/len(num_list)
-    except ZeroDivisionError :
-        return 0
+
def mean(num_list):
+    try:
+        return sum(num_list)/len(num_list)
+    except ZeroDivisionError :
+        return 0

If a single function might raise more than one type of exception, each can be caught and handled separately.

-
def mean(num_list):
-    try:
-        return sum(num_list)/len(num_list)
-    except ZeroDivisionError :
-        return 0
-    except TypeError as detail :
-        msg = "The algebraic mean of an non-numerical list is undefined. Please provide a list of numbers."
-        raise TypeError(detail.__str__() + "\n" +  msg)
+
def mean(num_list):
+    try:
+        return sum(num_list)/len(num_list)
+    except ZeroDivisionError :
+        return 0
+    except TypeError as detail :
+        msg = "The algebraic mean of an non-numerical list is undefined. Please provide a list of numbers."
+        raise TypeError(detail.__str__() + "\n" +  msg)
-

What Else Can Go Wrong?

+

What Else Can Go Wrong?

    @@ -82,7 +83,7 @@

    What Else Can Go Wrong?

-

Cause All of the Errors

+

Cause All of the Errors

    @@ -91,6 +92,15 @@

    Cause All of the Errors

Exceptions have the advantage of being simple to include and powerfully helpful to the user. However, not all behaviors can or should be found with runtime exceptions. Most behaviors should be validated with unit tests.

+ diff --git a/03-exceptions.md b/03-exceptions.md index c8ea0c0..f12174d 100644 --- a/03-exceptions.md +++ b/03-exceptions.md @@ -9,6 +9,7 @@ minutes: 10 > > * Understand that exceptions are effectively specialized runtime tests > * Learn when to use exceptions and what exceptions are available +> * Recognize the differences between exceptions and assertions Exceptions are more sophisticated than assertions. They are the standard error messaging system in most modern programming languages. Fundamentally, when an @@ -85,3 +86,12 @@ def mean(num_list): Exceptions have the advantage of being simple to include and powerfully helpful to the user. However, not all behaviors can or should be found with runtime exceptions. Most behaviors should be validated with unit tests. + +> ## Exceptions vs. Assertions {.callout} +> +> _Assertions_ can be thought of as your internal checks (as the developer) +> to make sure that your program is behaving how you would like it to. When you are writing tests for your own software, you should use _assertions_. +> +> _Exceptions_ can be thought of messages that you would like the actual user of your program to let them know that the program behavior is incorrect (e.g. because their input was not correctly formatted). +> A helpful mnemonic is that _Exceptions_ are _external_. + From 13495f3f14f9e232d4e170bb302620749d38e789 Mon Sep 17 00:00:00 2001 From: Arjun Biddanda Date: Wed, 9 Nov 2016 10:28:05 -0600 Subject: [PATCH 2/3] revised learning objectives to be active voice and an example on when to use exceptions rather than assertion --- 03-exceptions.html | 15 +++++++++------ 03-exceptions.md | 24 +++++++++++------------- 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/03-exceptions.html b/03-exceptions.html index 6767f34..052df78 100644 --- a/03-exceptions.html +++ b/03-exceptions.html @@ -34,9 +34,9 @@

    -
  • Understand that exceptions are effectively specialized runtime tests
    • -
  • Learn when to use exceptions and what exceptions are available
    • -
  • Recognize the differences between exceptions and assertions
    • +
  • Learner will understand that exceptions are specialized runtime tests
    • +
  • Learner will recognizes scenarios when to use exceptions and what exceptions are available
    • +
  • Learner will recognize when to use exceptions as opposed to assertions
@@ -47,7 +47,7 @@

raise Exception("The algebraic mean of an empty list is undefined. Please provide a list of numbers") else : return sum(num_list)/len(num_list) -

Once an exception is raised, it will be passed upward in the program scope. An exception be used to trigger additional error messages or an alternative behavior. rather than immediately halting code execution, the exception can be ‘caught’ upstream with a try-except block. When wrapped in a try-except block, the exception can be intercepted before it reaches global scope and halts execution.

+

Once an exception is raised, it will be passed upward in the program scope. An exception can be used to trigger additional error messages or an alternative behavior. Rather than immediately halting code execution, the exception can be ‘caught’ upstream with a try-except block. When wrapped in a try-except block, the exception can be intercepted before it reaches global scope and halts execution.

To add information or replace the message before it is passed upstream, the try-catch block can be used to catch-and-reraise the exception:

def mean(num_list):
     try:
@@ -97,8 +97,11 @@ 
Exceptions vs. Assertions
-

Assertions can be thought of as your internal checks (as the developer) to make sure that your program is behaving how you would like it to. When you are writing tests for your own software, you should use assertions.

-

Exceptions can be thought of messages that you would like the actual user of your program to let them know that the program behavior is incorrect (e.g. because their input was not correctly formatted). A helpful mnemonic is that Exceptions are external.

+

To resolve any possible confusion on when to use assertions as opposed to exceptions, we would like to make the following points.

+
    +

  1. Assertions can be thought of as your internal checks (as the developer) to make sure that your program is behaving how you would like it to. When you are writing unit tests for your own software, you should use assertions in those tests since the user will likely not see the tests.

    2. +

  2. Exceptions can be thought of as messages that you would like the actual user of your program to see to let them know that the program behavior is incorrect (e.g. because their input was not correctly formatted) or to trigger alternative program behaviors. Two particular cases where exceptions are useful is when there is a program failure, and when there are special results or cases that need to be handled. A helpful mnemonic is that Exceptions are external.

    3. +
diff --git a/03-exceptions.md b/03-exceptions.md index f12174d..ac9c342 100644 --- a/03-exceptions.md +++ b/03-exceptions.md @@ -7,9 +7,9 @@ minutes: 10 > ## Learning Objectives {.objectives} > -> * Understand that exceptions are effectively specialized runtime tests -> * Learn when to use exceptions and what exceptions are available -> * Recognize the differences between exceptions and assertions +> * Learner will understand that exceptions are specialized runtime tests +> * Learner will recognizes scenarios when to use exceptions and what exceptions are available +> * Learner will recognize when to use exceptions as opposed to assertions Exceptions are more sophisticated than assertions. They are the standard error messaging system in most modern programming languages. Fundamentally, when an @@ -27,14 +27,12 @@ def mean(num_list): ~~~ Once an exception is raised, it will be passed upward in the program scope. -An exception be used to trigger additional error messages or an alternative -behavior. rather than immediately halting code +An exception can be used to trigger additional error messages or an alternative +behavior. Rather than immediately halting code execution, the exception can be 'caught' upstream with a try-except block. -When wrapped in a try-except block, the exception can be intercepted before it reaches -global scope and halts execution. +When wrapped in a try-except block, the exception can be intercepted before it reaches global scope and halts execution. -To add information or replace the message before it is passed upstream, the try-catch -block can be used to catch-and-reraise the exception: +To add information or replace the message before it is passed upstream, the try-catch block can be used to catch-and-reraise the exception: ~~~ {.python} def mean(num_list): @@ -49,7 +47,6 @@ Alternatively, the exception can simply be handled intelligently. If an alternative behavior is preferred, the exception can be disregarded and a responsive behavior can be implemented like so: - ~~~ {.python} def mean(num_list): try: @@ -88,10 +85,11 @@ to the user. However, not all behaviors can or should be found with runtime exceptions. Most behaviors should be validated with unit tests. > ## Exceptions vs. Assertions {.callout} +> To resolve any possible confusion on when to use assertions as opposed to exceptions, we would like to make the following points. > -> _Assertions_ can be thought of as your internal checks (as the developer) -> to make sure that your program is behaving how you would like it to. When you are writing tests for your own software, you should use _assertions_. +> 1. _Assertions_ can be thought of as your internal checks (as the developer) +> to make sure that your program is behaving how you would like it to. When you are writing unit tests for your own software, you should use _assertions_ in those tests since the user will likely not see the tests. > -> _Exceptions_ can be thought of messages that you would like the actual user of your program to let them know that the program behavior is incorrect (e.g. because their input was not correctly formatted). +> 2. _Exceptions_ can be thought of as messages that you would like the actual user of your program to see to let them know that the program behavior is incorrect (e.g. because their input was not correctly formatted) or to trigger alternative program behaviors. Two particular cases where exceptions are useful is when there is a program failure, and when there are special results or cases that need to be handled. > A helpful mnemonic is that _Exceptions_ are _external_. From 83ca634a161b44e14f5a6f312f7d493d1dcfd93c Mon Sep 17 00:00:00 2001 From: Arjun Biddanda Date: Fri, 11 Nov 2016 15:18:53 -0600 Subject: [PATCH 3/3] revised typos --- 03-exceptions.html | 2 +- 03-exceptions.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/03-exceptions.html b/03-exceptions.html index 052df78..b727aaf 100644 --- a/03-exceptions.html +++ b/03-exceptions.html @@ -35,7 +35,7 @@

  • Learner will understand that exceptions are specialized runtime tests
    • -
  • Learner will recognizes scenarios when to use exceptions and what exceptions are available
    • +
  • Learner will recognize scenarios when to use exceptions and what exceptions are available
  • Learner will recognize when to use exceptions as opposed to assertions
diff --git a/03-exceptions.md b/03-exceptions.md index ac9c342..798df46 100644 --- a/03-exceptions.md +++ b/03-exceptions.md @@ -8,7 +8,7 @@ minutes: 10 > ## Learning Objectives {.objectives} > > * Learner will understand that exceptions are specialized runtime tests -> * Learner will recognizes scenarios when to use exceptions and what exceptions are available +> * Learner will recognize scenarios when to use exceptions and what exceptions are available > * Learner will recognize when to use exceptions as opposed to assertions Exceptions are more sophisticated than assertions. They are the standard error