You are in: RPG Cafe > Return code vs exception?
Short URL: https://ibm.biz/rpgcafe_return_code_vs_exception
RPG Cafe: Return code or exception?
Which is better, a return code or an exception?
When you are writing a procedure that might want to indicate an error condition, you have three choices: You can use the return value to indicate success or failure, you can have a separate "return code" parameter, or you can send an exception to indicate failure.
An application that uses exceptions is more robust than an application that uses return codes. An application that uses exceptions can also give the cleanest code, since return codes don't have to be checked after every call. Instead, several calls can be coded in one MONITOR block, assuming that the same error handling can be done for all errors.
When you write a procedure that requires the caller to add code to check a return code, then the application is weakened every time the caller fails to check the return code.
A sloppy programmer calls your procedures
Here is what the calling code looks like for each of those three mechanisms, when written by a sloppy programmer. The only one that is "safe" is the one where the procedure returns an exception. The caller didn't code an exception monitor, so the application crashes. I say this is "safe" because it's better to have an application crash due to an unmonitored error than it is to have it complete without crashing but instead working with invalid data.
rc = returncodeProc(); // Didn't check the return code errParmProc(errorCode); // Didn't check the error code exceptionProc(); // Didn't monitor for the error, but that's ok since // the application will crash and someone will notice
A careful programmer calls your procedures
Here is what the calling code looks like for each of those mechanisms, when written by a careful programmer.
rc = returncodeProc(); if rc = FAIL; handle the error condition; endif; errParmProc(errorCode); if errorCode = FAIL; handle the error condition; endif; monitor; exceptionProc(); on-error; handle the error condition; endmon;
Or, if the careful programmer wants the exception to percolate to a higher-level exception handler, they don't need the MONITOR:
Each mechanism causes awkwardness for some callers
What if the caller doesn't want to handle the error at that point, but instead, they want some higher-level monitor to handle the error. Now, the programmer has to do more work when they call the procedures that use return codes.
rc = returncodeProc(); if rc = FAIL; signal the error condition; endif;
if errorCode = FAIL; signal the error condition; endif;
Or what if the caller of the procedure that returns the exception doesn't want to leave the message in the joblog?
monitor; exceptionProc(); on-error; remove the message from the joblog; handle the error condition; endmon;
Best of both worlds
Wouldn't it be nice if the caller could choose how the function was written? Here's how to do that. It's similar to the way the system APIs are written. Write the procedure to signal an exception unless an optional errorcode parameter is passed.
Here's the sloppy programmer again. No error code parameter is passed, so the application crashes with an exception.
Here's the programmer who wants the exception to percolate to a higher-level handler. It looks the same as the call made by the sloppy programmer, and that's ok, since it means the procedure is easy to call.
Here's the programmer who doesn't want the exception to go to the joblog:
errParm_Or_ExceptionProc(errorCode); if errorCode = FAIL; // handle the error condition endif;
Use the return value for your application
When you use this mechanism, you are free to have your procedure return a useful value.
addr = get_cust_addr(id);
addr = get_cust_addr(id : errcode); if errcode.status = ID_NOT_FOUND; ... endif;
16 December 2019