The most troublesome bug is the occasional one; there is no definite way to reproduce it.
I've searched a lot on this topic,
and the most probable reason is the charset,
and I've taken some actions by setting the default charset as utf8 in .htaccess (I'm using Apache),
but it still happens, again occasionally!
Have you guys any tips other than setting the default charset to fix it?
As a side note that according to my own experience it happens mostly when the form is submitted from IE, if not all.
Are you using PHP?
Usually any time I hit a blank page, it's because there's an elusive bug in php someplace and errors are turned off.
Just an alternative path you might investigate.
Related
we're currently customizing iNotes for a customer (platform currently is Domino 9). We almost reached our goals, but one thing that's on our todo list I can't really figure out: they want us to also customize any possible error pages; see the following example screenshot:
This and other similar pages seem to come from the central Forms9.nsf which I'd love to leave as it is. We so far tried domcfg.nsf mappings, but as this is an iNotes internal error it obviously can't work; I also tried to figure out a way to put seomething into our customized Forms9_x.nsf but without any hint this is too abstract for me.
So my questions are:
has anyone ever done this?
what options do we have (apart from "hacking" Forms9.nsf)?
Many thanks in advance...
Update:
After continuing to play with domcfg mappings I suddenly saw a first result; not sure what's the difference to the first attempts, though; maybe moving the error form to Forms9_x.nsf did the trick? I'll keep investigating and post an answer if I can find one...
Alright, this has been an afternoon of wild guessing and hacking along, but finally I think I found it:
first of all, my playing around with domcfg mappings didn't have to do with solving the problem; instead, I just by chance had put my error page form into my Forms9_x.nsf and named it $$ReturnGeneralError (that's simply the name used in Forms9.nsf...; I completely had forgotton about those 4 pre-defined form names back from Domino 5 times).
What did not work was the old method of simply including a text file named MessageString to display the exact error message returned from the server; obviously iNotes is handling those error strings differently.
After a few hours of testing, and comparing codes between the standard iNotes error page and mine I finally found it: include some iNotes specific computed text into the page, in my case that is
#{{MessageString}; html}
See this document for some details (last row in the table)
Hopefully this can help someone else as well...
All of a sudden, I'm seeing floods of first chance exceptions in the VS.NET Output window.
There are 3 of us working on the project. We've all updated our code to the latest in SVN and I'm the only one seeing all the exceptions, so the issue is not our app, but I suspect, some setting that I accidentally triggered in VS.NET.
If I right click the Output window, "Exception Messages" is checked. It always has been and is for my co-workers, so that's not the issue.
I cannot see any options in Tools/Options/Debugging that could be responsible. I suspect I probably just accidentally hit some accelerator key combo that did it. These appear to be perfectly normal first chance exceptions (like setting a property in a dynamic object for the first time causing a RuntimeBindingException). The app seems to operate just fine. But the flood of messages is annoying and makes debug output hard to follow.
By far the most common exception is an ArgumentException with the message, "A property with the name 'UriTemplateMatchResults' already exists."
We use WCF very heavily (but no REST) and have a number of WCF services that our app communicates with, so I'm assuming that's just standard WCF stuff because the calls are all working fine.
Can anyone think of anything I might have done?
I discovered the source of the problem. As I suspected, it was something I had accidentally done, but I'm not sure when or exactly how. Hopefully this solution will help others.
The solution was Tools/Options/Debugging in the General section, I had somehow unchecked Enable Just My Code. I'm not sure how I unchecked it. That fixed the problem.
First, thank you for taking pity on me and reading this issue. I CANNOT for the life of me figure out what extension I might have installed that is causing this issue, but it is EXTREMELY cumbersome.
Whenever I begin to type code (VB I think it also occurs in C#), for example "For Each" once I hit the F it forces a set of parentheses. Which would look like F(), but because I keep typing it looks like F(or). This only occurs when coding inside code blocks like a function or a sub, but when I'm creating the function it does not occur. I've disabled any and all power tools and the like, or at least I'm 90% sure I've done this for all of them, and yet it still occurs.
I'm usually pretty proficient at digging about the net and finding the answer, but for this one I'm at a loss. There is just too many keywords involved, so all I see is non-related topics, or how to make the parentheses occur, not get rid of them.
If anyone can provide some steps to resolve this, I'm happy and eager to try them. It's just such a hassle to live with for right now.
If you think it is a Visual Studio extension, then start by disabling all of them and adding them back one at a time.
You can also run VS with the command line switched to disable features.
Devenv switches
The simple answer to the cause is the Codealike VS Extension. I logged a bug with them and hopefully they'll fix it soon
here is the url send by solrnet
http://localhost:8983/m_review/maincore/select?facet.field=p_catalog_id&facet=true&fq=p_B2BShow%3a%5b1+TO+*%5d&fq=p_review_type%3a1&sort=p_review_date+desc&rows=4&q=%3a&?
the url always ends with &?
and the costed time during the search is 10 times slower than the normal url
how to solve this problem?
thanks in advance
It may be a bug, but I've never seen any perf or behavior difference because of it. Solr just ignores it.
You might want to try compiling the latest source and see if it fixes your issue. But as I said, I really doubt that's the real cause of a 10x slowdown.
I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.