and why the variable is bytes object rather than strand fix the problem at its source when we pass string where bytes are expected the error message is somewhat less obviousand differs between python and for examplein python traceback (most recent call last)file "program py"line in data write(infotypeerrorexpected an object with buffer interface in python the error message' text has been slightly improvedtraceback (most recent call last)file "program py"line in data write(infotypeerror'strdoes not have the buffer interface in both cases the problem is that we are passing string when bytesbytearrayor similar object is expected we can either perform the conversion--in this case by passing info encode("utf ")--or work back to find the source of the problem and fix it there python introduced support for exception chaining--this means that an exception that is raised in response to another exception can contain the details of the original exception when chained exception goes uncaught the traceback includes not just the uncaught exceptionbut also the exception that caused it (providing it was chainedthe approach to debugging chained exceptions is almost the same as beforewe start at the end and work backward until we find the problem in our own code howeverrather than doing this just for the last exceptionwe might then repeat the process for each chained exception above ituntil we get to the problem' true origin we can take advantage of exception chaining in our own code--for exampleif we want to use custom exception class but still want the underlying problem to be visible class invaliddataerror(exception)pass def process(data)tryi int(dataexcept valueerror as errraise invaliddataerror("invalid data received"from err hereif the int(conversion failsa valueerror is raised and caught we then raise our custom exceptionbut with from errwhich creates chained