Should caller/consumer handle the OpenSSL error?

[linuslin0]

What's your question?

jwt-cpp doesn't handle the OpenSSL error after OpenSSL calls, is that intentional? Should consumer handle the OpenSSL error instead?

Additional Context

Several functions in jwt-cpp like ecdsa::verify() uses OpenSSL APIs. However the OpenSSL error(s) are not popped in case of failure. If caller/consumer doesn't explicitly handle/clear the OpenSSL error queue, then such error(s) will become stale.
I am wondering if this is done intentionally, that the caller should be responsible of handling any OpenSSL error that could be rasied within the jwt-cpp? Thanks.

[Thalhammer]

It was intentional when I started building jwt-cpp about a decade ago, because it was mostly a small utility that got more and more abstracted over time (and hence useful to others), but I am open for debate if thats still the proper approach.

Nowadays things are a bit different. You don't have to deal with openssl anymore at all if you only want to build/parse/sign/verify tokens because the library abstracts all those parts away, so it might make sense to also handle all the OpenSSL errors (instead of just detecting and bailing out).

@prince-chrismc Might also wanna join this discussion.

Regardless of the outcome, its gonna have to wait for v0.8.0 because its a breaking change.