Raise custom exception instead of RuntimeError
#2504
Unanswered
browniebroke
asked this question in
Ideas
Replies: 1 comment 3 replies
-
|
I don't understand how changing the exception would make it easier for you. 🤔 You're sending the |
Beta Was this translation helpful? Give feedback.
3 replies
-
When it's raised, I catch it and move on with my life. Catching "RuntimeError" would be a bit too broad I think.
I don't know why it's doing that, and probably I should, but in the context of our project, it's much harder than the alternative I'm suggesting 😄 From the outside, changing the exception type to seemed like a relatively simple change and seemed like a good idea anyway, so I thought I asked, but I understand if you say no, it's 100% up to you at the end. |
Beta Was this translation helpful? Give feedback.
-
|
Part of the reason I'm not understanding why it's happening is because I'm not sending it directly, my app is implementing a specialised version of It seems that the error happens when my backend restarts (e.g. when a new version is deployed) and some operation gets interrupted... |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, I manage to uncover more details about this. It seems the server is being overloaded with too many connections: The first line comes from here: Line 256 in fe39100 From I can see, the server is shutting down, but a request is still being processed? Still digging why we're getting so many connections, we're probably not cleaning up after ourselves... Anyway, seems like an issue in our app I think, but in case someone comes across a similar issue. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We're using uvicorn with server side event in a Django application. We're sometimes getting some
RuntimeErrorraised by uvicorn:Looking at the uvicorn code, it seems perfectly reasonable to raise something, so I was thinking to catch the appropriate exception and do something with it when that happens. However, we have a few framework layers between where the exception is raised by uvicorn and our code, so catching for plain
RuntimeErrorseems a bit broad and I'm a bit concerned of hiding other issues.Would it make sense for uvicorn to define its own set of exception classes and raise them instead of raising built-in exceptions from the standard library? It would certainly make it easier for us to target and handle the right error.
Beta Was this translation helpful? Give feedback.
All reactions