Lab 3: Debugging and Error Handling

The lab provided details on debugging, fixing, or handling errors using try/except/finally blocks. The provided three scripts contain runtime error which were easily identified and corrected or properly handled. The output from these scripts are shown in the preceding Figures 1, 2, & 3. 

Figure 1 - Script 1 Output

Figure 2 - Script 2 Output

Figure 3 - Script 3 Output

Try/Except

For script three it was expected to not correct the exception but handle it with a try/except expression. This was simply a mater of identifying the specific error being raised and encapsulating the offending code and peer dependencies in a try/except. My solution was not to add a Pokemon catch but to explicitly catch the TypeError raised in the script.

The reason is professional peer review and automated code review systems, like SonarQube will flag Pokemon catch expression during audits. The premise is the that one should know and explicitly account for errors and deploy appropriate actions,  not just blindly catch "it-all".

Flowchart of Script 3

This script contain two processes which ran in sequence Part A and then Part B. The goal was to ensure that Part B would run whether Part A succeeded or failed.  Nonetheless, it is two independent process lumped into a single file. This is show Figure 4 and Figures 5 & 6 show the details about the two processes.

Figure 4 - Script 3 Generalized Flowchart

Figure 5 - Process A

Figure 6 - Process B