Description of the problem, including code/CLI snippet

Quite often (for "user facing applications"), I find myself "needing to explain" why this failed.

For example:

commit=pc_project.commits.get(pc_ref)

whichmagically ✨, can return:

args= (<gitlab.v4.objects.commits.ProjectCommitManagerobjectat0x7ece058f5d60>,'10.8')kwargs= {}@functools.wraps(f)defwrapped_f(*args:Any,**kwargs:Any)->Any:try:returnf(*args,**kwargs)exceptGitlabHttpErrorase:>raiseerror(e.error_message,e.response_code,e.response_body)fromeEgitlab.exceptions.GitlabGetError:404:404CommitNotFound.venv/lib/python3.12/site-packages/gitlab/exceptions.py:348:GitlabGetError

Now, you'd be right to claim PEBCAK. However, is it PEBCAK because the usersomewhere wrote the inputwhich eventually becomes input to this function as:

• 123456..., or, because he wrote
• 2025.09expecting that thispc_ref isindeed any kind of ref, while the programmer expected it to be only a commit ref?

Same goes for:

• .branches.get(from_branch) (404 Branch not found)
• .project.files.get (404 File Not Found)

and maybe others - I will update as I find them.

I think the dissonance here happens because Gitlab's API expects "you did hand-held API operations" (/api/v4/projects/15/repository/commits/2025.09, ergo a 404 ismuch more obvious why), vs, when python-gitlab throws an exception, you don't even have access to theactual request attempted (path for GET requests, andadditionally payload forthe rest of the operations)

Expected Behavior

"Somehow" enhance stacktraces, so that the stacktrace is more actionable.

Actual Behavior

Specifications

• python-gitlab version: 6.4.0
• Gitlab server version (or gitlab.com):