Best practices coding c++ [closed] - c++

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm wondering, is there a better way to write code when there are functions with status returns.
Below is an example. (Please ignore simple code errors if there are any. I'm specifically talking about the structure. Plus, I'm at work and don't have a compiler on this computer)
#include "Session.h"
Session::Session(const char * IPaddress, unsigned int openPort)
{
ssh_session mySession;
hostIP = IPaddress;
port = openPort;
}
int Session::cBeginSession()
{
try
{
int status = ssh_options_set(mySession, SSH_OPTIONS_HOST, &hostIP);
if (status == 0)
{
status = ssh_options_set(mySession, SSH_OPTIONS_LOG_VERBOSITY,
SSH_LOG_PROTOCOL);
if(status == 0)
{
status = ssh_options_set(mySession, SSH_OPTIONS_PORT, &port);
if (status == 0)
{
std::cout << "Session started\n";
return 0;
}
else
{
std::cout << "Unable to set port\n";
return -3;
}
}
else
{
std::cout << "Protocol option log verbosity unable to set\n";
return -2;
}
}
else
{
std::cout << "Unable to set Host address\n";
return -1;
}
}
catch (...)
{
std::cout << "Unknown exception occurred\n";
return -8;
}
}
I typically use if-else statements with the status parameters, but I tend to end up with large nests of if-else statements if there are more than one or two functions involved. Is there a more readable way to write something like this? It turns into a rats nest very quickly.
EDIT: Thank you for all the replies. I think I have some ideas of how to structure my code better. I appreciate all the diligent suggestions.

Answer 1

In modern C++ programming, typically, if you encounter an error where the program can't continue, then I think it's better to throw an exception.
So your function would wouldn't return anything (i.e. void). Whenever it ran into a can't continue situation, you would throw an exception that tells what the error is. The calling code would then deal with the error.
The advantage to this, is that you get to choose where to deal with the error. For example, the stack may unwind all the up to main.
You code could look like this:
void Session::cBeginSession()
{
if (ssh_options_set(mySession, SSH_OPTIONS_HOST, &hostIP))
{
// throw an exception
}
if (ssh_options_set(mySession, SSH_OPTIONS_LOG_VERBOSITY, SSH_LOG_PROTOCOL))
{
// throw an exception
}
if (ssh_options_set(mySession, SSH_OPTIONS_PORT, &port))
{
// throw an exception
}
}
Once you get the hang of coding with exceptions, code tends to be cleaner and more robust since you're not always worrying about checking return codes.
EDIT
To answer you comment. You can choose how and when to handle the error. You can just catch the exception above your call. But, in general, if you want to do something that can fail (but not end a program) you can make another function that returns a boolean status.
bool Session::tryCBeginSession()
Now, your original function void Session::cBeginSession() would be implemented in terms of this new function. I've found that in most cases writing these dual functions is done only in a limited number of cases.

Answer 2

I like to reduce nesting, like this:
status = fcn1();
if ( status == 0 )
{
// something good
status = fcn2();
}
else
{
// something bad happened. report, and leave status reporting failure.
}
if ( status == 0 )
{
// something good
status = fcn3();
}
else
{
// something bad happened. report, and leave status reporting failure.
}
if ( status == 0 )
{
// something good
status = fcn4();
}
else
{
// something bad happened. report, and leave status reporting failure.
}
I like that error printing is close to the error occurrence. Sure, when failure happens, the status gets checked extra times. But it's a small price to pay for the simplicity.
This also lends itself well to de-allocation of resources and closing files at the end, regardless of where the error occurs.

Answer 3

You don't need if-else if you either return or throw in the statement that follows (this is a good case for throwing BTW). Plain ifs will do.
The type of messages you're printing are usually better suited to stderr rather than stdout (cerr rather than cout).
If you decide you will keep using error statuses, symbolic constants (or enums or defines) are usually preferred over "magic numbers"

Answer 4

This is a pretty ideal scenario for exception-handling (at least how it was intended). Exception-handling is typically appropriate for handling external input errors, as in this case where the external input is coming from a socket.
You already have a try/catch block, but I would suggest eliminating it since there's no recovery code. Keep your try/catch blocks generally focused around areas where you make a change transaction. Catching an exception then rolls back the changes, gets the system back to a valid state, and possibly outputs some message.
Something like this:
void Session::cBeginSession()
{
if (ssh_options_set(mySession, SSH_OPTIONS_HOST, &hostIP) != 0)
throw runtime_error("Unable to set Host address");
if (ssh_options_set(mySession, SSH_OPTIONS_LOG_VERBOSITY, SSH_LOG_PROTOCOL) != 0)
throw runtime_error("Protocol option log verbosity unable to set.");
if (ssh_options_set(mySession, SSH_OPTIONS_PORT, &port) != 0)
throw runtime_error("Unable to set port");
std::cout << "Session started\n";
}
Let the client code calling this function catch the exception at a site where it's appropriate to handle and recover from the error. Just worry here about throwing the exception appropriately in the case of these external input errors.
Note that exception-handling is typically ultra cheap in the non-exceptional cases (where you don't throw) with optimizations like zero-cost EH. However, these kinds of exception-handling compiler optimizations make the rare case much slower where you actually do throw an exception. So exceptions should be used for truly exceptional cases resulting from some kind of external input your software can't normally handle, as in this case.
Another caveat relevant in certain types of larger systems (plugin architectures, e.g.), is that typically exceptions should not be thrown across module boundaries.
This is somewhat opinionated but I don't recommend having lots of catch branches based on the type of exception (as commonly found in Java, e.g.). Often there isn't a need to distinguish the actual type of an exception so much as relay a message to the user, e.g. Catch exceptions as generally/coarsely as you can, and keep the try/catch blocks to a minimum (high-level transaction-oriented mentality: transactions succeed as a whole or fail and roll back as a whole).
Otherwise exceptions can really simplify these kinds of cases, and a whole lot of the C++ library (and even parts of the language) throw exceptions normally (I really think C++ and exception-handling are inseparably tied), so it can be useful to make use of them since a robust program will typically need to generally catch them anyway.

Answer 5

In this particular case (error codes handling), I'm advocating for early returns:
int status = ssh_options_set(mySession, SSH_OPTIONS_HOST, &hostIP);
if (status != 0)
{
std::cout << "Unable to set Host address\n";
return -1;
}
status = ssh_options_set(mySession, SSH_OPTIONS_LOG_VERBOSITY,
SSH_LOG_PROTOCOL);
if (status != 0)
{
std::cout << "Protocol option log verbosity unable to set\n";
return -2;
}
status = ssh_options_set(mySession, SSH_OPTIONS_PORT, &port);
if (status != 0)
{
std::cout << "Unable to set port\n";
return -3;
}
std::cout << "Session started\n";
return 0;
I find the code much more readable because it has lest nesting and the error handling is kept close to the point where the error occured instead of being buried in a far else branch.
If you decide it is best to use exceptions rather than error codes, you can keep the same structure and replace returns with throws.

Answer 6

some suggestions noted in the code:
// improvement - derive your own descriptive exception FROM A STANDARD EXCEPTION TYPE
struct session_error : std::runtime_error
{
using std::runtime_error::runtime_error;
};
// improvement in constructor: initialiser lists
Session::Session(const char * IPaddress, unsigned int openPort)
: mySession()
, hostIP(IPaddress)
, port(openPort)
{
}
namespace {
// use of anonymous namespace so this wrapper function does not pollute other compilation units
void setopt(ssh_session& session, int opt, const void* val, const char* context)
{
if (ssh_options_set(session, opt, val))
throw session_error(context);
}
}
void Session::cBeginSession()
{
// improvement - defer to wrapper function that handles nasty return code logic
// and throws a sensible exception. Now your function is readable and succinct.
setopt(mySession, SSH_OPTIONS_HOST, &hostIP, "setting host option");
setopt(mySession, SSH_OPTIONS_LOG_VERBOSITY, SSH_LOG_PROTOCOL, "setting verbosity");
setopt(mySession, SSH_OPTIONS_PORT, &port, "can't set port");
std::cout << "Session started\n";
}