A Data-Driven Approach to Writing Better Developer Documentation
The most impactful changes ParadeDB has made over the last year to its developer documentation.
Good error handling is key to robust programs, but often dreaded by programmers because there is always one more edge case. Traditional object-oriented programming languages use special exception classes that can be thrown to break the regular control flow for immediate error reporting. Let’s take a quick look at an example that explores error-safe integer division:
int safeDiv(int a, int b) {
if (b == 0)
throw Div0(); // Exceptions are passed out-of-line
return a / b; // Totally safe now, right?
}
Newer languages tend to favor functional-style error reporting and encode errors in their return type:
For example, Go encodes the error in the return type with an (res, err) tuple, and Rust returns Result<T, E>, a sum type of result and error.
Even older languages such as C++ now include error values in their standard library with std::expected: