Hi Walter, Thank you for bringing this up. As I understand it, you have a concern that the return value of hdfsGetLastExceptionRootCause will persist across multiple libhdfs calls, even calls that are successful. FWIW, I think that calling this function is only meaningful immediately after detection of a failed call. It's not meaningful to call this function after a successful libhdfs call.
By analogy, we can consider checking errno in the C standard library [1]. Documentation states that "the value in errno is significant only when the return value of the call indicated an error." There is no guarantee that subsequent successful C standard library calls will result in "clearing" errno or returning the prior error. Just don't look at it if later operations succeed. I don't think it looks like a bug, but please reply if you disagree, and I'm happy to discuss more. [1] https://man7.org/linux/man-pages/man3/errno.3.html Chris Nauroth On Fri, Dec 1, 2023 at 8:59 AM Walter Mitty <[email protected]> wrote: > Hello, > > When I read the codes of libhdfs, I found that the last exception string > was not cleaned before calling functions. > > In more detail, an exception will be saved in `ThreadLocalState` by > `setTLSExceptionStrings` if it throws in function calling, then the > subsequent calling of `hdfsGetLastExceptionRootCause` will return the saved > exception strings. But the problem is even if the subsequent calling of > other functions, eg `hdfsExists`, returns success, the ` > hdfsGetLastExceptionRootCause` still returns the former exception strings. > > The related code is in: > https://github.com/apache/hadoop/blob/5cda162a804fb0cfc2a5ac0058ab407662c5fb00/hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfs/jni_helper.c#L795-L809 > > Does anyone know if this behavior is expected? > > Thanks >
