You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently #81 was raised to troubleshoot a problem when downloading chapters, but the Tracebacks that were shared didn't have enough information to pinpoint exactly where the code actually broke and why.
This is because in base.py lines 391-403 of the DownloadChapterThread class we are re-raising a FatalError with just a short message but not preserving the original Traceback:
defrun (self):
try:
self.siteParser.processChapter(self, self.chapter)
exceptExceptionasexception:
# Assume semaphore has not been release# This assumption could be faulty if the error was thrown in the compression function# The worst case is that releasing the semaphore would allow one more thread to # begin downloading than it should## If the semaphore was not released before the exception, it could cause deadlockchapterThreadSemaphore.release()
self.isThreadFailed=TrueraiseFatalError("Thread crashed while downloading chapter: %s"%str(exception))
If an Exception is raised in any part of the underlying code in self.siteParse.processChapter(self, self.chapter) it will be silenced by the code on line 403 where we raise FatalError.
We need to find a way to either wrap the original exception properly in a FatalError, or just re-raise the original exception altogether so as not to lose our ability to hunt down bugs.
Unless I'm skipping something is raising our custom FatalError really giving us any value here?
The text was updated successfully, but these errors were encountered:
No, I agree that wrapping the exception diminishes the value instead of increasing it.
I'd check to see if any code depends on FatalError, and - if not - remove the wrapping.
I mean, if we really want to keep the wrapping I think it is still doable.
Granted, in Python3 we have the raise-from statement and it'd be easier,
but in Python2 we'd need to jump through a few hoops in order to implement
it correctly using sys.exc_info, we just need to take into account the
Warnings stated in the documentation:
Recently #81 was raised to troubleshoot a problem when downloading chapters, but the Tracebacks that were shared didn't have enough information to pinpoint exactly where the code actually broke and why.
This is because in
base.py
lines 391-403 of theDownloadChapterThread
class we are re-raising aFatalError
with just a short message but not preserving the original Traceback:If an Exception is raised in any part of the underlying code in
self.siteParse.processChapter(self, self.chapter)
it will be silenced by the code on line 403 where weraise FatalError
.We need to find a way to either wrap the original exception properly in a FatalError, or just re-raise the original
exception
altogether so as not to lose our ability to hunt down bugs.Unless I'm skipping something is raising our custom FatalError really giving us any value here?
The text was updated successfully, but these errors were encountered: