Capture All Errors and Exceptions: Score = 0
We get a big 0 for this one, and deservedly so. The code in Example 1-4 doesn’t handle any errors or exceptions. This is perhaps the single greatest problem with this code. It can fail, and when it does, we’ll have little or no idea as to why it failed. This makes it more difficult to recover and greatly reduces the resilience of the code.
Recoverability: Score = 2
We get a low score of 2 for recoverability. Why? Well, what happens if we encounter an error when the code runs? It just bombs out with no option to handle the problem. It will be difficult in this scenario to determine if the code ran to completion or stopped halfway through. As discussed, this is poor practice and is at odds with the needs of resilience.
Observability: Score = 0
A low score for observability is also bad news. It means that we have no easy way to see if the code ran successfully. Nor can we see any data changes that occurred as a result of the code run. Indeed, given that we have a call to COMMIT, the data change may well have occurred and then been reverted because of an error. In that case, the error causes the transaction to be rolled back. With low observability, we don’t get to see any of what happens behind the scenes. It’s as if the code hadn’t run at all.
Modifiability: Score = 5
The code in Example 1-4 isn’t all bad; it is easy to understand. This makes it more modifiable than might be the case in functional programming–style code blocks in languages such as JavaScript and indeed Java. In these languages, the code can be extremely difficult to understand and maintain. By contrast, the PL/SQL in Example 1-4 can be changed with confidence; this will be very useful when I start to look at refactoring this code in later chapters.
Modularity: Score = 2
The code in Example 1-4 has a structure that is fairly easy to understand. Thus, it can be converted into a callable unit of code, such as a PL/SQL procedure. Modularizing code in this way helps in promoting reuse, such as creating packages of useful PL/SQL code. Such packages can then be shared with other developers. This has numerous benefits that will be seen later.
Simplicity: Score = 5
Example 1-4 is pretty easy to understand even though it uses a CURSOR abstraction. The CURSOR abstraction may be (unnecessarily) viewed as a complex programming construct. As we’ll see, CURSORs are a fundamental unit of PL/SQL and they provide a lot of algorithmic power and safety. Simplicity is a key requirement of resilience, because it forces us to think about the avoidance of overly complex code.
Coding Conventions: Score = 5
The code in Example 1-4 certainly looks like it might be based on a defined coding convention. Typically, this governs elements such as:
- Spacing
- Variable names
- Style of comments
- Length of code blocks
Good coding conventions are very useful and can make it easier for different teams in an organization to manage each other’s code, such as developers and/or DevOps groups.