Bug #122232 for SMB: Control of and access to error handling

I notice that errors such as authentication failures are reported using warn, which is a problem because it means that the modules produce undesirable and uncontrollable output (modules should never write text to STDOUT or STDERR unless explicitly requested unless output is expected for a good reason). Errors in modules should be handled by calling code. Calling code errors in SMB are handled via die, but not situational errors (authentication errors, protocol errors etc) which are handled instead with warn. For example, Client::connect_tree will die if there are missing parameters, or return undef if something else went wrong; in the latter case the caller is not able to identify why undef was returned: the error is held in the local variable $response which is discarded when the method terminates. The authentication relies on process_request, which will issue a warning ("SMB Error on ...") but not store this error anywhere: only the caller (here, connect_tree) gets the response inside $response. connect_tree does have access to the $response object and the error it contains, but personally I prefer exception handling and to always die() immediately on error. This way, you only have to deal with the error in one place: connect_tree can safely assume that it if process_request returned, then it succeeded; it can catch the error with eval and throw/rethrow should it need to clean up following an error. However, I appreciate that some people prefer to use a function such as ->lastError to see what went wrong and return undef. The SMB classes don't offer any mechanism for the calling code to manage errors, and such a mechanism is needed. While I will need to amend my local copy of Client.pm to die within process_request, the decision on how best to approach this lies with the maintainer(s) of the project.