After updating the JDK on my development workstations, NetBeans started reporting the following at each start up.
Cannot locate java installation in specified jdkhome:
C:\Program Files\Java\jdk1.7.0_04
Do you want to try to use default version?
[ Yes | No ]
Thankfully, after a little searching, I found that the solution is very simple. You can change the value or comment it out with a # in:
C:\Program Files\NetBeans #.#.#\etc\netbeans.conf
netbeans_jdkhome="C:\Program Files\Java\jdk1.7.0_04”
REFERENCES:
IE overrides several HTTP error status pages but it has a size threshold. Only if the error page send by the server has a large enough body then IE decides it’s meaningful and displays it.
Usually to be safe you should make error pages that are larger then 512 bytes. The threshold varies per HTTP status code. You can look at what your thresholds are currently set to. In IE 5 and greater the settings are stored in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\ErrorThresholds]
Err Size(bytes):
- 400 512
- 403 256
- 404 512
- 405 256
- 406 512
- 408 512
- 409 512
- 410 256
- 500 512
- 501 512
- 505 512
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: browser, custom, error, friendly, http, ie, messages, msie, registry, server, windows
This is a relatively common problem in JSP based apps as you need to understand the configuration. It’s further complicated if you use Apache HTTPD in front of the Apache Tomcat server to process requests as you need to know where each request is processed.
For this example, we will use the standard 404 error, but you can also intercept other errors for custom pages.
- create 404.jsp
<% final SimpleDateFormat simpleDate = new SimpleDateFormat(”EE MMM dd yyyy hh:mm:ss aa zzz”);
final String dttm = simpleDate.format(new Date()); %>
<html>
<title>404 Not Found</title>
<ul>
<li>Time: <%= dttm %></li>
<li>User-Agent: <%= request.getHeader(”User-Agent”) %></li>
<li>Server: <%= request.getServerName() %></li>
<li>Request: <%= request.getRequestURI() %></li>
<li>Remote: <%= request.getRemoteAddr() %></li>
<li>Referer: <%= request.getHeader(”Referer”) %></li>
</ul>
</html>
- in WEB-INF/web.xml – add the following (NOTE: location within the file is important but outside the scope of this post)
404
/404.jsp
- You might want to force the HTTP Header to give something other than a ‘404 status’ code, otherwise MSIE will show an unstyled ‘friendly error message’ if the user has not turned off the default setting. Unfortunately, this also means that search engines might index these pages that should not exist.
REF:
Categories: MSIE bugs, WebStandards, Work Tags: 404, apache, error, html, http, jsp, networking, page, tomcat
I’ve found that many developers (including myself) that have been coding javascript for some time don’t realize that javascript added the try/catch pattern from Java quite a while ago and that all modern browsers support it.
Here’s the standard pattern, the ‘finally’ of course is optional for when you require it.
try{
// put your code here that may experience a runtime error/exception, i will show division by zero in this example
var x = 1;
alert(x/0);
}
catch(e){
if(e instanceof Error){
alert(’an error has occurred:name=’ + e.name + ‘|message=’ + e.message);
} else {
alert(’an unknown exception has occurred’);
}
}
finally{
alert(’now we are done’);
}
A little more on this… like in Java, there are types of Errors, and you can rely upon ‘instanceof’ to determine them appropriately, here are a few of the common types in JavaScript 1.5:
- EvalError
- RangeError
- ReferenceError
- SyntaxError
- TypeError
- URIError
REFERENCE:
http://www.devarticles.com/c/a/JavaScript/Exception-Handling-in-JavaScript-Using-Multiple-Exception-Handlers/
Cheers
I’ve programmed in a lot of different languages, and with various IDE’s. The one area that has always been lacking is a simple means to review JavaScript code for common errors, both syntactical and format. This is where JSLint and JavaScript Lint come in…. these represent the tooling previously available to other languages like C++ and Java, where you can analyze code without actually executing it to identify problem areas. Often, these are items like ‘missing semicolons’ that occasionally cause difficult to find errors in browsers.
These can be scripted to execute from the command line or within (some) IDE’s on several operating systems.
Categories: WebStandards, Work Tags: code, data, error, files, javascript, js, jscript, jshint, jslint, lint, quality, recover, review, salavge, script
I’ve installed and managed dozens of MySQL installations for several years, occasionally it seems that an install just doesn’t run like it has in the past.
Recently I had a problem where the service would not start (Error 1067) on Windows Server 2003 (R2)… which is running under VMWare. After checking the obvious places and turning up nothing I started down the list of potential solutions exposed by Google search.
The ultimate solution it seems is that the ‘my.ini’ file needed to include the specific path information required by the service…. without it the service would not start.
Here’s my current file (c:\windows\my.ini) for reference:
[WinMySQLAdmin]
Server=C:/mysql40/bin/mysqld-nt.exe
[mysqld]
basedir=c:/mysql40
datadir=c:/mysql40/data
For the really observant readers of this entry… you will notice that this is for MySQL 4.0 (which is no longer officially supported). It’s mostly used as it is widely compatible across various host systems that are sometimes problematic with newer releases.
Cheers.
Debugging JavaScript errors is a time-consuming effort requiring keen eyes and a sharp mind.
MSIE typically only gives a cryptic ‘Object Expected’ error message and little more (even with the Microsoft Script Debugger installed!).
Some tools like FireBug and the Venkman debugger (both for Mozilla/Firefox) help in this matter, but often it helps to have an alert when an issue occurs.
Here’s a simple implementation that I’ve found useful…
[script type="text/javascript"]
window.onerror=myErrorHandler;
function myErrorHandler(msg,url,l){
var txt=”There was an error on this page.\n”;
txt+=”Error: ” + msg + “\n”;
txt+=”URL: ” + url + “\n”;
txt+=”Line: ” + l + “\n\n”;
txt+=”Click OK to continue.\n\n”;
alert(txt); return true; }
[/script]
REFERENCES:
That’s it….
Categories: WebStandards, Work Tags: browser, catch, client, debug, error, exception, html, javascript, notification, onerror