Debugging in a server-side Swift project

There are in general two types of errors: one occurs in runtime and the other takes place during code compilation. Runtime errors are expensive because they are difficult to track and tackle. Swift enforces strong type checking to reduce the chance of your mistake slipping through compilation error checking and become a runtime error. Unit tests with good code coverage also help you discover problems during development time. However, when a runtime error does occur, you'll need a better strategy to cope with it.

This is especially true for a server-side project because it is hard to reproduce the same condition that caused a runtime error to happen when there could be so many different kinds of networking conditions and situations. Normally, you'll set breakpoints in your code for some conditions which you suspect to have caused an error, and then inspect the state of your code when an error did get triggered. In a server-side project, not all conditions are reproducible if a condition is caused by some external factors, such as the available capacity in the network infrastructure or the network bandwidth availability in the data center, which are out of your control.

Given the nature of problems common to server projects, there are some debugging techniques that could be more useful than others. Logging is one of those debugging techniques that is useful for a server-side Swift project. A logging framework provides useful utility functions that allow you to record, manage, and store useful logging information in your project. When a runtime error occurs, it allows you to trace back the steps that lead to a failure.