Error Code

The CeeLanguage doesn't have exceptions but it still has to deal with errors. if you're sure there are no possible errors then you can code simply:

  double compute_something(double a, double b);

but often, there is always some possible error. so the way this is handled is by returning the result in an output variable, and returning an ErrorCode. for example:

  int compute_something(double* result, double a, double b);

one might think that it'd make sense to have the return value be "true" non-zero for success and "false" zero for failure. but in practice, people use ZeroIsSuccess and NegativeIsFailure?. so checking for errors looks like:

  error_code = compute_something(result,a,b);
  if ( error_code<0 ) {
    // handle error
  }

Windows API's provide enumerations of some sort like HRESULT with zero represented by a constant ending in OK. like S_OK or RESOURCE_OK. so the idiom looks like this:

  if ( error_code != S_OK ) {
    // handle error
  }

Now comes the differentiation part. We want to KeepErrorInformation so that we can try to find out what the actual error was so we can handle it. it could be considered similar to "catching the exception". this is where patterns diverge. there are two main patterns:

there are also functions like socket that return -1 for error, zero for success, and positive is the file descriptor. so it doesn't quite do the pattern the way i describe it.

A dedicated "error result" would be nice (returning a tuple of two values) so that the error doesn't bloat up the code with another parameter.

An out or var parameter bloats up the function declaration:

   function blah(foo, bar: string; out error: integer): string;

Versus below which returns a tuple:

   function blah(foo, bar: string): string; error;

Where above function returns an string, and an error as an integer (using maybe dot notation on the result, to check the error). I find errors that bloat up the parameter lists just aren't elegant, but I also don't find I like hidden exceptions in some downstream code for all errors. Many errors are predictable (like fileExists, should return just a boolean for example, and no error check needed.. since fileExists would be the error check itself)).

If the coder doesn't check the error result, then the compiler should complain if that warning is on. With hacks like getLastError or getErrNo (checking a global error value), there is no compiler checks saying "you forget to error check!". For quick prototyping, one could turn off error checks and allow the function to act normally.. but it wouldn't be recommended practice.