Ensure proper Exception inheritance in APIException subclasses

[RinZ27]

I noticed that APIException and ValidationError were overriding __init__ without calling super().__init__(). While DRF handles its own self.detail logic, skipping the base Exception.__init__ leaves exc.args empty. This can cause issues with error-tracking tools or logging middleware that expect standard exception attributes.

This change ensures that all DRF exceptions properly populate their base attributes while maintaining existing functionality. I've updated the initialization chain to ensure super() is called correctly throughout.

[Copilot]

Pull request overview

This PR addresses a gap in exception handling by ensuring that DRF's custom exceptions properly call their parent Exception.__init__() method. This fix ensures that standard exception attributes like args are properly populated, which is important for compatibility with error-tracking tools and logging middleware that rely on these standard attributes.

Changes:

• Updated APIException.__init__() to call super().__init__() with the processed detail
• Updated ValidationError.__init__() to call super().__init__() instead of directly setting self.detail

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[RinZ27]

@thawancomt It primarily affects interoperability with standard Python tooling. Since exc.args remains empty, any logging middleware or error-tracking services (like Sentry or custom OpenTelemetry exporters) that rely on inspecting args to extract the exception message or context will end up with missing data.

For example, a simple str(exc) on a standard Python exception normally returns its first arg, but here it might not behave as expected if the base class isn't initialized. By calling super().__init__(), we ensure DRF exceptions are "well-behaved" members of the Python exception hierarchy without breaking any existing DRF-specific logic.

[thawancomt]

I get it now, thx man

[browniebroke]

While DRF handles its own self.detail logic, skipping the base Exception.init leaves exc.args empty. This can cause issues with error-tracking tools or logging middleware that expect standard exception attributes.

I'm not sure I follow, here is what I'm getting on main:

>>> from rest_framework.exceptions import *
>>> e = ValidationError("Invalid input")
>>> e.args
('Invalid input',)
>>> e2 = APIException("test", 123)
>>> e2.args
('test', 123)

So it seems to me that exc.args is set properly?

After a quick query, this is apparently set by BaseException.__new__, not Exception.__init__...

As far as I can tell, we don't need this change. Unless. you wanted to do something else?

[browniebroke]

Not passing down the code to this one? This changes the representation of the exception in the REPL and make it quite verbose:

Before

>>> APIException("Invalid input", 400)
APIException('Invalid input', 400)

After

>>> APIException("Invalid input", 400)
APIException(ErrorDetail(string='Invalid input', code=400))

[browniebroke]

Similar comment on verbosity.

Before

>>> ValidationError("Invalid input", 400)
ValidationError('Invalid input', 400)

After

>>> ValidationError("Invalid input", 400)
ValidationError([ErrorDetail(string='Invalid input', code=400)])

[RinZ27]

@browniebroke You're right, and I appreciate you taking the time to actually test it. args is populated via BaseException.__new__, so the whole premise here falls apart — calling super().__init__() explicitly doesn't change anything observable.

Closing this one.