   return a description or just a bool
  I like returning a struct from most my functions that contain what called it and what caused the error. It's basically just to make finding what is crashing and why for me, but I'm wandering if that is proper to do that, or do most people just return a bool or even void?quick example.struct result{    string objectName;    string errorDescription;    bool error;};// function result MyFunction(){    if (an error occured)    {    return result("MyFunction", "MyFunction Failed to do something!", true);    }}
  It's a reasonable idea, if return values are appropriate. Sometimes exceptions may be the better choice, depending. You'll also need another solution for functions that return actual values.   ;  In some cases, exceptions might be a superior option. In others, you might split a function into smaller pieces where there is only one possible failure.In any case, I'm not sure what the point of "objectName" is. Is it so you can pass the error up the call hierarchy and still locate the point at which the error was generated? Are your error descriptions not unique enough to discriminate?   ;  The way several libraries do it (Including Win32) - although I'm not saying it's a good way, is to return a boolean to indicate success / failure, but to log the error details and have another function to access the error details (GetLastError() in Win32). If you're writing plain C code, that could be a reasonable option, but if you're using C++, then exceptions would probably be a better solution.   ;Quote:Original post by rip-offIn some cases, exceptions might be a superior option. In others, you might split a function into smaller pieces where there is only one possible failure.In any case, I'm not sure what the point of "objectName" is. Is it so you can pass the error up the call hierarchy and still locate the point at which the error was generated? Are your error descriptions not unique enough to discriminate?exactly, in my renderer's create function I've included a texture manager and other smaller chunks of the renderer that have functions called within the main function. So if Renderer::Create() fails, it really says nothing about what failed or why.   ;  I would really recommend against returning a large complex structure like that just for error handling. The problem is that even when no error is being reported you still have the overhead of the return copy. Also, if you don't mind using some platform dependent code, a better option than using the objectName mechanism could be to use a stack trace to show exactly where your function is failing.   ;  A common approach in C APIs is to return an integer, 0 means success and any other value is a particular error code. The API provides a function to map the error code to a human readable string. Its cheap and cheerful, lacking only the "objectName" part of your requirements.   