You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Curretnly all errors are reported by returning an error code, which is in itself not a problem, however if a function should also return a value, problems arise. One is that the error codes have to share the type with the return value and second, the error codes limit the range of valid values that can be returned from a function.
A better approach would be to have the function return value reserved for errors, while havnig the function result returned through a parameter.
For example:
intfoo_new(structfoo*f, intbaz) {
if (baz) {
*f= (structfoo) {.bar=3};
returnOK;
} else {
// something went wrongreturnERR;
}
}
This way the caller can check the return code to see if the value was set or not before using it.
If we did the inverse where the result is returned through function return and the error code set through a parameter like so:
structfoofoo_new(intbaz, int*status) {
if (baz) {
*status=OK;
return (structfoo) {.bar=3};
} else {
// something went wrong*status=ERR;
return ??? // What do we return?
}
}
We wouldn't be able to handle failures properly.
The return error / set result may not be ergonomic as the original way, but it allows for more flexibility in error reporting.
The text was updated successfully, but these errors were encountered:
Curretnly all errors are reported by returning an error code, which is in itself not a problem, however if a function should also return a value, problems arise. One is that the error codes have to share the type with the return value and second, the error codes limit the range of valid values that can be returned from a function.
A better approach would be to have the function return value reserved for errors, while havnig the function result returned through a parameter.
For example:
This way the caller can check the return code to see if the value was set or not before using it.
If we did the inverse where the result is returned through function return and the error code set through a parameter like so:
We wouldn't be able to handle failures properly.
The return error / set result may not be ergonomic as the original way, but it allows for more flexibility in error reporting.
The text was updated successfully, but these errors were encountered: