I've been looking around for a solution for several hours now, and maybe I'm just missing something..
I've a factory that implements protocol.ReconnectingClientFactory which works just fine, however, whenever the program ends running, I get a bunch of Unhandled error in Deferred messages in my log for each disconnection that occurred during runtime, such as
2012-06-14 12:28:51+0100 [-] Unhandled error in Deferred:
2012-06-14 12:28:51+0100 [-] Unhandled Error
Traceback (most recent call last):
Failure: twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion: Connection lost.
Is there any way I could somehow "handle" these during runtime, so that my log wouldn't be spammed with this at the end.. (or avoid it being spammed somehow..) I really don't care what the solution is, I already have the following method that logs everything for me
def clientConnectionLost(self, connector, reason):
log.msg('Lost connection. Reason: %s' % reason)
is there anything I could do with the "reason" in there, which is the Failure object, so that the error would be properly handled..?
Anyway, I don't claim to be anywhere near proficient in Twisted, so any help would be greatly appreciated.
Thanks a lot in advance.
The message Unhandled error in Deferred is telling you where the error comes from and even hinting at how to eliminate it. When a Deferred is garbage collected with a Failure result, it logs these messages - because the error wasn't handled.
Add an error handler (and errback) to the Deferred that fails this way, and handle the error however you want (including ignoring it, if that's what's appropriate for your application).
Related
I'm working on an app and everything is working fine, then I began to get this error when I log things out from try-catch block
Error: An error was thrown when attempting to render log messages via LogBox.
Please what could cause this?
i had the same issue and i spend all most two days to find any solution and in the end i find their is one console.log() statement which is logging the entire redux store, so as soon as i removed the console statement error removed.
I received silent crashes, and in order to find their reasons, I collected a crash dump. When I try to debug it, I get the error
Exception thrown at 0x748E89EA (msvcrt.dll) in app.exe.10228.dmp:
0xC0000005: Access violation reading location 0x0457351A.
I can’t find out exactly where this error occurs, because it occurs spontaneously during working.
After all, in vb.net there is no direct memory access, where could this error be? Is it possible that it is from the dll files that the program uses?
Call stack of thread in which appeared exception:
ntdll!NtWaitForMultipleObjects+c
KERNELBASE!WaitForMultipleObjectsEx+133
KERNELBASE!WaitForMultipleObjects+18
kernel32!WerpReportFaultInternal+3b7 kernel32!WerpReportFault+9d
kernel32!BasepReportFault+19 KERNELBASE!UnhandledExceptionFilter+2a2
ntdll!__RtlUserThreadStart+3a4e6 ntdll!_RtlUserThreadStart+1b
I have a vb.net desktop application and I am using thread.Abort() there.
I am getting system.threading.threadabortexception error.
Below is the error messagebox i am getting but not everytime.
Unhandled exception has occured in your application. If you click
Continue.....
Thread was being aborted.
Please suggest how to avoid this errormessage.
Please suggest how to avoid this error message.
The best, and correct, way to avoid this is to not call Thread.Abort(). Thread.Abort() is really a bad idea in general. Instead, you should build your routines around the cooperative cancellation model built in the framework.
I've run over a somewhat little problem over the week. The error message upfront this is about:
[30-Dec-2012 15:19:32] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
I think it is because my error handler (see below for details) is turning any error into an exception. I might should prevent that in case there is no stack frame.
Is there an easy way to find out if there is any stack frame or not in PHP?
Details:
On one of my websites I've got an error handler running that is turning every error into an exception, the common ErrorException to be precise.
I introduced it some time ago because the site is mainly legacy code and I wanted to have any issue result in an exception I can finally "catch" in a streamlined fashion an exception handler and give the request a stop.
I put this into class of it's own, the handler is registered and also in parallel an output buffer is opened to catch the output up until the exception is thrown. Basically code like this:
// register output buffering
$r = ob_start(array($this, 'handleBuffer'));
// register error handler
$this->_originalErrorHandler = set_error_handler(array($this, 'handleError'));
// register exception handler
$this->_originalExceptionHandler = set_exception_handler(array($this, 'handleException'));
This worked all fine and dandy until I decided to add another output buffering class into the mix. Just one that catches as well all output and then can do some "post production" on the website, including checking for HTML problems (yes, it's all a bit legacy so actually this is a bit duck-taped, I know). That also worked very fine btw. however not when I made a mistake in the new component:
[30-Dec-2012 15:19:32] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
This is basically my problem. Is there an easy way to prevent getting these errors? I somewhat know why the error is given but I'm not so entirely sure so it's hard for me to really circumvent the problem. I tried to release the new output buffer before the script enters the new shutdown phase because I thought this would cause this. But this didn't make it.
Your problem indicates that you are using an EOL (End Of Life) version of PHP (specifically PHP < 5.3.0), which means it's no longer supported. This issue comes from throwing an exception where no strack frame exists and as such the old engine did not know how to handle those exceptions properly.
This can be due to a couple of different reasons. Some of the most common ones are as follows:
You threw an exception from inside an error handler or exception handler.
You threw an exception from inside a destructor.
You threw an exception from inside a callback (like an output buffering callback function).
Here's an example that demonstrates your problem under some of those circumstances...
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
throw new ErrorException($errstr, $errno, 0, $errfile, $errline);
}
function myExceptionHandler($exception) {
echo "We got an exception with message: '{$exception->getMessage()}'";
}
function myCallBack($contents) {
trigger_error('ohnoes!'); // You can't throw an error from the output buffer callback function in older versions of PHP < 5.3
}
class Foo {
public function __destruct() {
trigger_error('ohnoes!'); // You can't throw an error from a destructor in older versions of PHP < 5.3
}
}
set_error_handler('myErrorHandler');
set_exception_handler('myExceptionHandler');
The above code would cause you to see the fatal error you described here...
ob_start("myCallBack");
... and here...
$foo = new foo;
This problem has been fixed in PHP >= 5.3.0 so you should not see this issue if you were using the most current version of PHP.
The simplest fix is to upgrade your PHP. If that is not an option you must consider these facts that you can not throw exceptions where PHP does not expect them to be thrown (in callback functions, error handlers, exceptions handlers, etc... -- which are actually all considered to be callbacks to PHP).
The other thing is you should not be turning every error into an exception in this way. If what you are doing is as the code I supplied demonstrates (i.e. throwing an exception from inside the error handler -- thus turning every error into an exception) then you are going to cause yourself a lot of pain and with virtually no benefit. PHP errors are not meant to be handled. They are meant to inform the client of a problem (the client being the person writing the PHP code), or potential problem. Handling the error itself is not as simple as turning every error into an exception and then handling that exception, because not every error should be exceptional. For instance, E_NOTICE level errors have no place in exception handling. They are primarily used to notify you of a potential for a bug, not that there is necessarily something buggy with your code and not to mention that most of them can't even be handled easily in user-space code (they mostly require re-factoring the code itself). I strongly advice against this poor practice.
I have a JRuby/Rails application comprising a web server to process HTTP requests, a MySQL database, and a Resque worker to process enqueued jobs. When I'm in development mode and something in the web application throws an exception, I get a nice trace in the browser, showing the exception thrown, the line at which it was thrown, relevant data, and a stack traceback.
However, when exception-throwing code executes in a Resque worker, I get nothing, even if I know that the code has thrown an exception. The only way that I can debug is to throw in print statements and figure out where the last print statement was called before the Resque worker threw the exception and crashed.
Is there a way to get the Resque worker to spit out an exception log and stack traceback into the log file (before it crashes), so that I can see what happened?
EDIT - (Thanks for the idea #Viren) - And I don't want to litter my application code with begin/rescue blocks. I'll put the begin/rescue code in once somewhere to make sure that the exception traceback gets logged, but I don't know where to put it.
You can set your Resque logger to use the Rails logger. For full stack trace you might want to set it to DEBUG level, which prints out lots of information. You put it in initializers/resque.rb:
Resque.logger = Rails.logger
Resque.logger.level = Logger::DEBUG
There also resque-backtrace gem, although it has this drawback that it overwrites the backend in Resque so now no jobs will ever make it to the error queue.