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.
Related
I'm working on an interface where the user creates an entity and gives it a name via a simple JS alert prompt, and by design our back-end returns a 422 error if you submit a name that already exists in the database. My task is to then display a message on the front-end after this error happens.
I'm using accept_prompt(with: "NAME") to properly test the modal functionality, but I'm having a hard time telling Rspec to expect an error from the attempted POST that results from completing the prompt.
I've tried the code below and variations of it but it always seems like Rspec fails with "no error was raised" and then immediately fails with ActiveRecord::RecordNotUnique: PG::UniqueViolation: ERROR(the exact error I'm trying to expect).
expect do
accept_prompt(with: "NAME") do
find(".selector .selector-item:first-child").click
end
end.to raise_exception
I've even tried the below code to no avail:
expect accept_prompt(with: "NAME") do
find(".selector .selector-item:first-child").click
end.to raise_exception
Is there some other known way to expect an error from a modal interaction in Rspec, or is it simply not possible?
We just resolved the issue, turns out the 500 error in the spec was caused by a problem with my spec configuration, unrelated to the 422 error that we expected to get and handle in the interface. Once we addressed that issue the 500 error went away and did not break the test, allowing us to continue running assertions against the frontend error validation.
So while there doesn't seem to be a way to actually catch and expect a backend error using Capybara, we didn't need to because that error wasn't supposed to be happening.
This is about NodeJS and Express. I want to add an error handler that simply logs the error in my preferred way. This way also takes care of console output. I don't want, at this point in time anyway, to replace the functionality of the Express default error handler. I want the default error handler to continue doing its thing for the time being, with one exception: Since my logging already took place, and also covers console output, I want the default error handler to pretty much stop adding to the console.
My question is: How do I accomplish this? I did some searching and found nothing, so unsure if I may be using the wrong keywords.
All of a sudden the errors that Dojo (1.8.3 from Google CDN) is spitting out empty errors, which makes debugging impossibly hard. For example, if I forget to require a dependent before using it, I get the usual
> dojo/parser::parse() error ReferenceError {}
... in the error console, but I remember getting more information in the ReferenceError (spindown arrow was present), giving me the arguments of the error as well as the message making it easy to figure out what I had done wrong.
I have isDebug : true in my dojoConfig, but it just doesn't want to tell me anything anymore.
What gives?
I've been having the same problem using Dojo 1.8.3 as well. When I close my developer tool's console and then re-open it the Error had the spindown and more details as expected. Seems stupid, but give it a try and see if that at "fixes" it for you. I planned on digging a little further into this later, so if I find any additional details I will make sure to update my answer with them.
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.
In classic asp page, i need to catch the error description and insert into a table in the database.
when i use 'on error resume next', i am getting a timeout error as follows:
The maximum amount of time for a
script to execute was exceeded. You
can change this limit by specifying a
new value for the property
Server.ScriptTimeout or by changing
the value in the IIS administration
tools
Please help me to catch the exception and insert into database.
I believe your question is "How do I trap the Script Timeout error and record it in the database". Then the answer is you can't do it with On error resume next.
The problem is that ASP has determined your script has run for too long. In order for your code to trap and record the error your code needs to continue but that is exactly what ASP has determined shouldn't happen since its time is up.
Also in general unless you can continue to do something sensible (and that does not include logging) in your script there is no point trying to use On Error Resume Next to trap the error.
Instead create a new ASP script that should run whenever you get a script error (this will include a Script timeout error). In IIS manager open your applications property dialog and select the Custom Errors tab. Edit the handler for the 500;100 HTTP error and change it to URL and the path of this ASP script.
Now you can place your error logging code in this ASP script. You can access the error thrown by the failing ASP page by accessing the Server.GetLastError method. You can also configure this page to send something friendly to the user.
If the exception is with anything to do with your database you might have found your answer... have you checked to see what the problem is first?
Why not investigate/fix the timeout issue rather than try and catch the exception? Whilst you should log errors you should also investigate why it is occuring in the first place.