Fortran - Errors and error handling - Part 6 - Guarantees
Parsing an array of strings to a polyline should fail if one of the strings could not be parsed to a string. But it should also fail if the resulting array of points is empty. Or at least, if that makes sense in the application’s domain. You could say that a polyline with no points is still a polyline, just like an empty set is still a set. Similarly, in some scenarios it may be okay for a polyline to have just a single point. For now, let’s skip the mathematical discussion and take this as a practical rule that we want to enforce: a polyline has at least 2 points. The type we currently have can’t give us such a guarantee:
By Matthias Noback
read moreFortran - Errors and error handling - Part 5 - Error propagation
Parsing a string to a point may not be successful, and we were able to communicate that to users of parse_point()
by returning a custom type called point_or_error_t
.
What if we want parse not just one point but a set of points, forming a polyline, from a list of strings? The result of parsing each string separately is a point or an error. Only if the list of those point_or_error_t
values contains no error at all should we consider turning the points into a polyline. If any of the values is an error, we shouldn’t make a polyline of the other valid points, but instead return an error: “Could not create polyline from strings. Previous error: Could not extract two decimal numbers from …” With this error we communicate what we were trying to do at the highest conceptual level (create a polyline), and what lower-level error caused this to fail.
By Matthias Noback
read moreFortran - Errors and error handling - Part 4 - Using an Either type
We looked at optionally returning a value from a function. In the case of average
it was an average value, or no value at all. In some more elaborate functions, the “no result” case needs some more explanation to the caller of the function. We may feel the need to communicate what went wrong, or for what reason. This gives the user the opportunity to pass better input next time, or fix some external issue that the program can’t fix itself (e.g. a file not being readable).
By Matthias Noback
read moreFortran - Errors and error handling - Part 3 - Preventing edge cases with types
In the previous post we introduced an optional_real_t
type to be the return value of an average
function, because depending on the size of the array of numbers passed to it this function may or may not return a real
value.
What if we could just prevent people from calling the average
function when they don’t have any numbers? Maybe we’re lagging too far behind if we have to verify the size of the array inside the average
function.
By Matthias Noback
read more