When calling methods, primitive data types are passed by value, while objects and arrays are passed by reference. This means when you call a method with an object as a parameter, you are merely providing that method a way to access/manipulate the same object via a reference; no copy is made. Contrast that with primitives: When calling a method that requires them, a copy of that value is put on the call stack before invoking the method.

In that way, references are somewhat like pointers, though they obviously cannot be manipulated by pointer arithmetic. But what about weak references? What are they, and how do they contrast with strong references?

Weakly understood

Based on my experience, the concept of weak references, or more generally reachability, is not one that is well-understood in the Java world. At least I did not have a good grasp of them until stumbling upon some sample code one day. It may be that the need to utilize them is outside the confines of most day-to-day programming tasks, as the concept is fairly low-level. Nonetheless, it’s an important concept to understand.

Basically, Java specifies five levels of reachability for objects that reflect which state the object is in, in relation to being marked as finalizable, being finalized and being reclaimed. They are, in order of strongest-to-weakest:

1. Strongly Reachable
2. Softly Reachable
3. Weakly Reachable
4. Phantom Reachable
5. Unreachable

An object’s normal state, as soon as it has been instantiated and assigned to a variable/field is strongly reachable. Chances are, these are the only types of objects you’ve worked with. We’ll first cover the concept of weakly reachable objects, as I believe it provides a good base for understanding the remainder.

Cleaning out the trash

Going by the API reference, a weakly reachable object is one that can be reached by traversing (i.e. going through) a weak reference. That’s a succinct definition to be sure, but it just raises the next question: What is a weak reference?

Simply put, if an object can only be reached by traversing a weak reference, the garbage collector will not attempt to keep the object in memory any more than it would an object with no references to it, i.e. an object that cannot be accessed. Thus, from the garbage collector’s point-of-view, a weakly-referenced object will eventually be cleaned from memory the same as an object no references to it.

So, if weakly-referenced objects are treated the same as completely non-referenced ones, what is the purpose of the weak reference? A good example is the WeakHashMap, a class provided by Java.

WeakHashMap

Unfortunately, WeakHashMap may also be poorly understood, probably as a result of weak references not being well known. WeakHashMap may at times be described as a “cache” of sorts, where objects/entries that are not used will be removed to decrease memory usage. This is not how WeakHashMap works at all.

The best way to describe a WeakHashMap is one where the entries (key-to-value mappings) will be removed when it is no longer possible to retrieve them from the map. For example, say you’ve added an object to the WeakHashMap using a key k1. If you now set k1 to null, there should be no way to retrieve the object from the map, since you don’t have the key object around any more to call get() with. This behaviour is possible because WeakHashMap only has weak references to the keys, not strong references like the other Map classes.

Note that for the WeakHashMap to work this way, as it was intended, the key objects must only be considered equal if they are actually the same object – i.e. object identity instead of mere equality. This is the default behaviour for Object.equals() and Object.hashCode(), so if these methods have not been overridden, the object is OK to be used as a key in WeakHashMap. Objects like Integer are not suitable for use in WeakHashMap, because it is possible to create two separate (non-identical) objects that are both equal:

final Integer i1 = new Integer(4);
final Integer i2 = new Integer(4);
LOGGER.debug("i1.equals(i2): " + i1.equals(i2)); // True.
LOGGER.debug("i1 == i2: " + (i1 == i2)); // False.

Another point of importance is that String is not a suitable key for a WeakHashMap as well. In addition to its overriding of equals() and hashCode(), String objects in Java are also interned (i.e. stored) in a pool by the JVM when created. This means that they may remain strongly referenced even after you have apparently gotten rid of your reference to them. Because of this, entries that you add to a WeakHashMap using String keys may never get dropped, even after you have apparently lost reference to the keys, since the Strings may remain strongly referenced in the string intern pool.

An example of String interning:

final String s1 = "The only thing we have to fear is fear itself.";
final String s2 = "The only thing we have to fear is fear itself.";
LOGGER.debug("s1.equals(s2): " + s1.equals(s2)); // True.
LOGGER.debug("s1 == s2: " + (s1 == s2)); // May also return true!

String objects are interned for performance reasons, so when you are going to create a new String, Java first checks if there is a String in the pool that is “equal” to the one you are creating. If such a String exists, the existing object is just returned instead of having to instantiate a new object. This is possible because Strings in Java are immutable, i.e. operations that appear to modify a String (such as concatenation, toUpperCase(), etc.) really return a new String object while preserving the original.

The last usage note is that even though the keys are weakly-referenced by WeakHashMap, the values remain strongly-referenced. Thus, you must take care to not use value objects that strongly reference the keys themselves, as if this happens, the keys/entries will no longer be automatically dropped because a strong reference may always exist to the keys. (This can be avoided by wrapping the value object in a WeakReference, so that both keys and values are weakly-referenced when in the WeakHashMap)

Example use of WeakHashMap

Here is a brief, albeit contrived example of WeakHashMap at work:

// SampleKey is just an object that holds a single int. (Use instead of
// Integer, since Integer overrides equals() and hashcode())
SampleKey key = new SampleKey(42);
SampleObject value = new SampleObject("Sample Value");

final WeakHashMap<SampleKey, SampleObject> weakHashMap = new WeakHashMap<SampleKey, SampleObject>();
weakHashMap.put(key, value);

// At this point, we still have a strong reference to the key. Thus, even
// though the key is weakly-referenced by the WeakHashMap, nothing will
// be automatically removed even if we give a hint to the GC.
System.gc();

LOGGER.debug(weakHashMap.size()); // Will still be '1'.
LOGGER.debug(weakHashMap.get(key)); // Will still be 'Sample Value'.

// Now, we if set the key to null, the entry in weakHashMap will eventually
// disappear. Note that the number of times we have to 'kick' the GC
// before the entry disappears may be different on each run depending
// on the JVM load, memory usage, etc.
key = null;
int count = 0;
while(0 != weakHashMap.size())
{
  ++count;
  System.gc();
}
LOGGER.debug("Took " + count + " calls to System.gc() to result in weakHashMap size of : " + weakHashMap.size());

Finishing up

In an upcoming article, I plan on covering the other types of references (soft and phantom) as well as the associated Reference classes in Java. I wanted to keep this post brief so that it provided a basic understanding of the situation.

Changes/Fixes

• 2011-04-10: Fixed numerous incorrect usages of the term “dereference”. Thanks to Ranjit for the explanation.

References

1. Package java.lang.ref
2. WeakHashMap
3. Understanding Weak References

With JavaScript there are actually two concepts at play when using logical operators: What is actually returned from the result of a logical operation, and how variables are converted to boolean values when the context requires it.

Undergoing a conversion

Firstly, we’ll look at how variables in JavaScript are converted to boolean values. One way to explicitly convert a non-boolean value to a boolean one in JavaScript is to use the global Boolean object as a function. By using the following code, you can explicitly get the boolean conversion of a variable or expression:

var asBoolean = Boolean(someVariable);

The variable asBoolean is now guaranteed to have a boolean value. Note that this is not the same as the expression new Boolean(someVariable), as that returns a Boolean (wrapper) object representing the converted value of someVariable, not a boolean primitive.

So what values of someVariable will result in true being returned, and which ones will result in false? The following values will evaluate to false, while all others will evaluate to true:

• 0 or -0 (Most floating-point implementations have positive and negative zero, due to the IEEE 754 standard)
• null
• undefined
• NaN
• The empty string (“”)
• false itself

This means that all other expressions or values, including any non-null object (including the Boolean object for false!) and the string “false” will be converted to true.

Note that using the Boolean function isn’t the only way to explicitly convert a variable to its boolean equivalent. You could also apply the logical NOT operator twice, like so:

var asBoolean = !(!someVariable);

This is because the contract of the logical NOT operator in JavaScript is to return false if the operand can be converted to true and true otherwise. The second NOT simply reverses the negation done by the first NOT operator. While all of this may seem dead simple, it will be important to note as we move on to how other logical operators work.

Logical conversion

This is perhaps the most important difference with JavaScript. Although the logical NOT operator (!) is guaranteed to return a boolean value, the logical AND (&&) and logical OR (||) operators are not. This is by design, and although it might be a bit of a change for some developers, the feature can actually be quite useful.

Consider the following code examples:

var result = a && b

In this example of using logical AND, a is returned if it can be converted to false; otherwise b is returned.

var result = a || b

In this example of using logical OR, a is returned if it can be converted to true; otherwise b is returned.

This means that one of the original operands or expressions used with the logical operators will be returned as a result of the evaluation. You will not always get an actual boolean value, unless both of the operands were booleans to begin with. Usually, this doesn’t matter, since if you use the result in a boolean context, it will get converted to the expected value. For example:

var string1 = "";
var string2 = "a string that is not empty";
var result = string1 || string2;
if (result)
{
  window.alert("At least one string was not empty");
  window.alert(result);
}

This example will output “At least one string was empty”, and then “a string that is not empty”. This is because the logical OR operator first converts string1 to a boolean, which results in false. Thus, the result of the logical OR returns string2 into the result. Since the result is now a non-empty string, it converts to true for the if-conditional.

This also highlights a convenient way of using logical OR – give me the first expression if it evaluates to true, otherwise give me the second. This is usually used to test for the availability of built-in objects in a particular JavaScript environment.

However, consider the following example:

var string1 = "";
var string2 = "a string that is not empty";
var result = string1 || string2;
if (true == result)
{
  // We will never get here.
  window.alert("At least one string was not empty");
  window.alert(result);
}

In this slightly changed example, instead of directly supplying the result to the if-conditional, we test whether it is equal to true. In this case, it fails, since when using the equality operator, operands are not converted to booleans. (Using the strict equality operator also would not work)

This underscores an important point: If you actually want a boolean value to work with, you will have to explicitly convert it, using either the Boolean function or a double application of the logical NOT operator, like so:

result = Boolean(result);
// Or, we could do this:
result = !(!result);

Conclusion

JavaScript offers some neat features due to its dynamic typing and these can help speed development, but you just need to be aware of how they work so that you don’t get tripped up. This is especially true when dealing with implicit type conversion and how logical operators work. I hope you found this helpful and as always, any feedback is appreciated!

References

1. Logical Operators
2. Boolean Object
3. Boolean Description
4. Comparison Operators

A bit of background

However, what I want to discuss today relates to certificate chains. At the top of every certificate chain is a root CA, whose certificate is self-signed. This sort of certificate can be considered a “God certificate” because it essentially says, “Trust me, because I say so”. As you can imagine, that’s not much of an argument for trusting someone, so that is why your browser has a list of default root CAs that it automatically trusts.

Some default trusted CAs in Firefox.

These root CAs are owned and operated by companies that are in the business of issuing certificates to other people for use on their servers. They have been added to the default trusted list of most browsers so that an end user doesn’t need to manually add all of them; doing so would be a usability nightmare. Essentially, these root CAs provide a trust anchor point, as not only are they trusted, but any certificates they issue will also be automatically trusted by the browser. Attempting to visit a HTTPS/SSL website that does not have a trusted certificates results in a nasty warning from modern browsers.

Rarely is the root CA certificate directly used for a web server, but instead it is used to sign or issue other certificates that are then used on a web server to confirm its identity and provide for secure end-to-end communication.

As you can imagine, operating a CA is an immense responsibility, so that is why these default lists have been setup: Essentially these companies have to vet entities that purchase certificates from them, to make sure they actually own the domain that they are trying to buy a certificate for, otherwise phishing would become too easy! Even so, these companies sometimes still have lapses due to use of outdated technologies and poor security practices, but that is another complicated issue for another day.

Issuing a certificate – An example

The act of issuing a certificate essential entails a CA using its public-private key pair to sign the contents of the certificate that is being issued. This ties the identity information in the certificate to its key pair and provides confirmation that the CA has affirmed the authenticity of the certificate, I.E., that it has truly issued this certificate and that it has not been forged.

Going back to a certificate chains, it was previously mentioned that the root CA certificate is at the top of the chain. Any certificates it issues are directly below it, so if these certificates are directly used on a web server, then the chain is of length two. However, certificate chains can be longer. If a certificate chain is longer than two, then this indicates the presence of an intermediate CA.

An intermediate CA is a CA that does not have a self-signed certificate but still has the capability to issue certificates that are trusted. For an example of the root CA to intermediate CA relationship, we can look at the certificate chain returned from https://mail.google.com:

The Root CA certificate from VeriSign, an X.509 v1 certificate.

Above we see the root CA certificate, a self-signed certificate created/issued by VeriSign. I’ve highlighted the fact that it is an X.509 version 1 certificate, which also means it doesn’t have any certificate extensions. This may not mean much right now, but we’ll get back to it soon.

The Intermediate CA certificate from Thawte, an X.509 v3 certificate.

This next shot shows the intermediate CA certificate that was issued by the root CA. This certificate has been issued to Thawte, a company coincidentally founded by Mark Shuttleworth, the South African man behind Canonical/Ubuntu. Thawte was acquired by VeriSign during the dot-com craze for US $575 million.

The “Basic Constraints” extension of the intermediate CA.

We can clearly see that this certificate is an X.509 version 3 certificate, meaning it does support certificate extensions. One of its extensions is a Basic Constraints extension, which has been set to signify that this is indeed a Certificate Authority. It also specifies one other parameter, which is the maximum number of intermediate CAs allowed beneath this one in the certificate chain hierarchy. Since this value is set to 0, this means this intermediate CA cannot issue any more CA certificates, but instead can only issue client certificates. Any attempt will to use a client certificate from this CA as a CA or signing certificate will fail, when consumed by a conforming client.

The client certificate

The last screenshot shows the client certificate, which is the last certificate in the chain. This is the certificate that is used by the server at mail.google.com to secure HTTPS traffic, and as we can see, it is also an X.509 v3 certificate (has extensions) and one of those extensions is the “Basic Constraints” extension. This time it is set to indicate that this is not a CA certificate.

The Basic Constraints of the client certificate, indicating it is not a CA certificate.

Basic Contraints – Why it’s needed

The “Basic Constraints” extension is one way for a CA to control the usage of the certificates it issues. For instance, when the root CA certificate in the example above issued the intermediate CA certificate, it set the Basic Constraints extension to signify that:

• The issued certificate is for a Certificate Authority, i.e. an intermediate CA.
• This certificate may not be used to create further CA certificates

In turn, the intermediate CA certificate was used to create the client certificate for mail.google.com, and it attached a Basic Constraints extension to signify that this certificate was not a CA certificate. By doing this, it was indicating that this certificate should not be used to sign/create further certificates.

This is necessary because of the how trust relationship works in X.509 PKI. Someone who trusts the root CA implicitly trusts all the intermediate CAs, and then by extension, all the client certificates issued by those intermediate CAs! (Note how this creates a single point-of-failure at the root CA as well)

If the CA could not control what the certificates it issued were used for, then someone could purchase a VeriSign certificate and use it to sign/create other certificates which would also be trusted by default! Clearly, this is not desirably from a security or financial point of view, if you are VeriSign. By using extensions such as the Basic Constraints one, the signing CA can enact fine-grained control over how the certificate is used. If the client certificate was used to sign another certificate, that certificate would be rejected by a browser that conformed to the X.509 v3 specifications.

The Grey Area

However, we run into a “grey area” of sorts when faced with a certificate that does not have a Basic Constraints extension. In this case, it is not indicated whether this is a CA certificate or not. How do the browsers respond in this scenario? In this case, it seems to depend on whether the CA is a root CA or an intermediate one.

For root CA certificates, it seems that the Basic Constraints extension is not required in order for the CA certificate to be viewed as valid from the browser’s point of view. (I’ve observed this in Firefox and Internet Explorer) This most likely stems from the fact that there are root CAs that were created and put into operation well before X.509 v3 extensions were in wide use. The VeriSign root CA in our example is an X.509 v1 certificate with a starting validity date of 1996-01-28.

However, for intermediate CAs, it seems that the Basic Constraints extension is required if you want things to work, at least in Firefox and Internet Explorer. I encountered this situation when working with a Private Root CA of my own. I was trying to create an intermediate CA (without any Basic Constraints extension) from this root CA, and was running into problems when using this intermediate CA to create client certificates. Any of the client certificates from the intermediate CA were being essentially rejected by the browser when attempting to visit the website they were being used for.

Because this was a “grey area”, the results were mixed. In Firefox, the site would load correctly, however when attempting to view the certificate chain (by double-clicking the lock icon in the lower right), only the client certificate could be viewed, not the fully certificate chain. Internet Explorer would show the full certificate chain but simply failed to load the page. Neither browser gave any indication as to why things were failing.

However, once I created an Intermediate CA with a Basic Constraints extension set to explicitly signify that this was indeed a CA, everything worked as expected. I don’t believe this is well-documented, though this is understandable since most people will not be creating their own Private CAs unless it’s for a very specialized purpose.

How to do this using the Bouncy Castle APIs

I’ve talked about the Bouncy Castle Java APIs before, and they have been an invaluable resource for simplifying the creation of a Private CA and for issuing certificates.

When issuing a certificate it’s fairly easy to set the Basic Constraints extension to indicate you want the certificate to be a CA certificate. First, take a look at this guide to under the fundamentals of certificate creation with the Bouncy Castle APIs, then look at this code fragment:

private static final int NUM_ALLOWED_INTERMEDIATE_CAS = 0;
...

// Construct the certificate.
final X509V3CertificateGenerator certGen = new X509V3CertificateGenerator();

...

// Need this extension to signify that this certificate is a CA and
// can issue certificates. (Extension is marked as critical)
certGen.addExtension( X509Extensions.BasicConstraints, true, new BasicConstraints(
  NUM_ALLOWED_INTERMEDIATE_CAS ) );

...

final X509Certificate intermediateCaCert = certGen.generate( signingCaPrivateKey, "SunRsaSign" );

By doing this you ensure that the intermediate CA certificate has the proper Basic Constraints extension to work correctly with modern web browsers.

Conclusion

I hope you found this helpful. Certainly if you’re here, you’ve been puzzled over the same issues that I struggled through!

References

1. X.509 Public Key Certificate and Certification Request Generation
2. OID 2.5.29.19 – Basic Constraints
3. OID Repository – basicConstraints(19)

I’ve written about Eclipse and how useful it can be, with its extensible plugin-based system. It’s so useful that I use it everyday for almost any language – Java, PHP, JavaScript to name a few. It’s even great for things like CSS and XHTML.

PHP is currently my favourite “hobby” language and has been for some time. While I like PHP, one of the things that hasn’t been straightforward with it is setting up a proper debug session, where you can step through code. This contrasts heavily with a language like Java, which has always had strong developer tools. This has resulted in a mass of third-party tools aimed at facilitating PHP debugging. A while ago, a reader emailed me asking about this very topic, so I decided to put together how-to detailing my experience with the topic and how I went about learning it.

Xdebug for PHP and XAMPP

The debugger I’ll be using will be Xdebug. Because PHP provide no built-in debugging tools, there are many third-party options for debugging. (See the “Debugging Tools” section of this article for more) However, Xdebug seems to be one of the more popular ones, and Eclipse PDT already has support for it.

This guide also assumes use of XAMPP, the great all-in-one solution for quickly setting up a web development environment and to get your code running on the server. XAMPP is great for hitting the ground running, though you’ll probably not want to use it in a production environment – though you likely won’t be debugging there either. Nevertheless, the instructions provided here should work even if you’ve setup Apache and PHP separately on your own.

Getting started

The first thing you’ll want to do is head over the Xdebug page and download the appropriate Zend extension of Xdebug corresponding to the version of PHP you’re running. Save the file into your PHP extension path/folder. Now you’ll have to edit your php.ini file to begin using the plugin. The plugin basically exposes or provides an interface for the client debugger (running in Eclipse or your IDE) to attach to the server and debug/trace through the code that’s running on it. If you’re from the Java world, you’ll know this as “remote debugging”, which is provided by most J2EE application servers.

You’ll also want to have downloaded Eclipse PDT have that installed as your IDE, if you haven’t already done so. Zend Studio for Eclipse also works, since it’s based on Eclipse PDT, and offers quite a few more features, out of the box.

Setting up Xdebug

You should have already saved the Xdebug extension DLL file to your PHP extension folder. Record down the full path of it. Now, open up your php.ini file and go down to the [XDebug] section, or create it if it’s not there. Uncomment or add the following lines:

;; Only Zend OR (!) XDebug
zend_extension_ts="D:\XAMPP\php\ext\php_xdebug.dll"
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

The zend_extension_ts should point to location of your Xdebug extension DLL that you downloaded earlier; modify as appropriate.

Then, you should disable the Xdebug entry in the list of dynamic extensions. This is confusing, but since we are already setting up Xdebug as a Zend extension, we don’t need another entry. Disable the Xdebug dynamic extension by ensuring the following line is commented out, like below:

;extension=php_xdebug.dll

There is one last very important step you need to do, particularly if you are running XAMPP. Current versions of Xdebug are incompatible with the Zend optimizer that is enabled by default in XAMPP, so you must disable that if you want Xdebug to work. If you don’t, you’ll notice that Apache will crash every time you try to load it with Xdebug enabled. To disable the Zend optimizer, find the [Zend] section in php.ini and comment out all of the entries under it, like so: (This is an example, there may be more to comment out)

[Zend]
;zend_extension_ts = "D:\XAMPP\php\zendOptimizer\lib\ZendExtensionManager.dll"
;zend_extension_manager.optimizer_ts = "D:\XAMPP\php\zendOptimizer\lib\Optimizer"
;zend_optimizer.enable_loader = 0
;zend_optimizer.optimization_level=15
;zend_optimizer.license_path =

You should be able to start Apache now without troubles.

Configuring Eclipse for PHP debugging

The next part will be configuring Eclipse as a debugging client. Since the code will be executing on the web server (Apache), you’ll need Eclipse to “hook in” using the Xdebug protocol. Thankfully, configuring Eclipse is fairly straightforward.

Open up Eclipse’s preferences and go to PHP -> Debug, and ensure that XDebug is selected as the PHP debugger. This sets the default for debugging sessions and lessens the configuration required for each debug session. You can also make sure that the default web server is localhost if that’s the case, which it’ll likely be for a lot of people doing development.

Note that if you are running Zend Studio, you’ll need to follow the steps in this article to enable Xdebug support. It seems that some versions of Zend Studio by default disabled support for the Xdebug plugin in lieu of their own Zend Debugger.

Now you can select a file from a project you’d like to debug. In my case, I’ve selected src/demo/index.php from my Challenge-Response PHP Login System project. Open the file, and then go to the Run Menu and select Debug Configurations… or Open Debug Dialog.

Double click the the “PHP Web Page” entry on the left side bar to create a new debug profile. Here, I’ve named it “CHAP-PHP”. You should see a dialog like the one above. Make sure the “Server Debugger” is again set to Xdebug and that the PHP Server is set to the localhost configuration you set up previously.

Then you have to select the file you want to debug. Click on “Browse”, and you’re confusingly taken to another view of your Eclipse projects; simply select the same file as before – you have to select a specific file, and not just a project or folder.

After that, you’ll need to adjust the URL mapping. You’ll probably need to uncheck “Auto Generate”, and then enter the URL that corresponds to the PHP file you’re debugging. Here, I’ve manually entered /projects/CHAP/trunk/src/demo/ as the URL fragment that triggers execution of the script.

If you want the debugger to stop right at the first line to allow you to immediately begin stepping through code, check “Break at First Line”. (It may be checked by default) Otherwise, uncheck it if you only want the debugger to stop at the breakpoints you’ve specified in Eclipse, which is the normal behaviour most developers will expect.

You should now be able to click “Debug”, and a debug session will launch, opening up the URL you’ve specified and allowing you to step through code. If you don’t like Eclipse using its own internal web browser (which appears just be a front for IE), you can configure which web browser you’d like it to launch URLs with by opening up Preferences and then going to General -> Web Browser and changing the setting to use an external web browser of your choice. Personally, Firefox is my preference.

Start your debugging engines!

You can now get acquainted with stepping through code, which in my opinion, is one of the best ways to learn! When you launch a debug session, Eclipse should prompt you to switch to a new “perspective”, which is just a different layout of Eclipse’s internal windows that many believe better suit debugging through code.

You’re provided with an informative view of the script your currently debugging, along with the highlighted line that execution has paused on. You can set debug breakpoints by double-clicking in the left margin of your source code view window; debug breakpoints show up as blue circles here. The buttons at the top (green “Play”, red “Stop” and others) provide control over execution of the code, allowing you to step through code line-by-line, step into functions/methods and return from them. I encourage you to experiment with all of the controls and get acquainted with the keyboard shortcuts.

Another panel also shows all the current variables available to the script as well as their values. This is useful since you now do not need to echo anything to output or change any of the code to see values.

When you’re done, you can just click the red “stop” button to disconnect from the server and end the debug session. If you’ve completely stepped through a script, you will not be automatically disconnected from the server. Instead, the debug client in PHP will patiently wait to debug the script again the next time it is executed. This is useful to know, since you can just go back to the URL in your web browser and reload the page to trigger the debug session to resume again.

Conclusion

I hope you found this useful, as when I was starting out trying to get a PHP debug session to work, it was somewhat frustrating. As always, I welcome your comments, suggestions and questions below via the comments form!

References

1. Why does xdebug crash apache on every XAMPP install I’ve tried?
2. Xdebug: Documentation
3. How to enable the Xdebug debugger in Zend Studio for Eclipse
4. Debugging PHP applications with Xdebug

One thing they handle well is the concept of certificate extensions. X.509 v3 certificates introduced the concept of these extensions, which are basically additional (potentially optional) fields containing information not contained in the older original X.509 specifications. Each extension is specified by an OID (Object Identifier); a good list of these extensions is available.

While it’s easy to read these extensions from an existing X.509 v3 certificate using the Bouncy Castle APIs it is a bit more involved to read these extensions from a Certificate Signing Request, or CSR; this is the data structure that is sent to a CA to request a certificate. The CA then reads the data from this and creates a signed certificate issued to the requester. In this guide I’ll present a brief way to extract X.509 extensions request from a CSR so that they may be included in the resulting issued certificate.

Code: The good stuff

Assuming you have added the Bouncy Castle JARs to your classpath, you should have access to the classes used here.

You must first have the CSR in the format of a Bouncy Castle data object, namely the PKCS10CertificationRequest. If all you have is the PEM-format of the CSR (i.e. Base64-encoded contents delimited by headers like ----- BEGIN CERTIFICATE REQUEST ----- and ----- END CERTIFICATE REQUEST -----) then you will need to convert this to the proper data structure using something like
PEMUtil from Commons-SSL like I have done below. (BC has a PEMUtil class as well, but it appears to be only for internal use)

// NOTE: Commons-SSL doesn't support generics.
final List pemItems = PEMUtil.decode( csrContent.getBytes() );

// Verify list isn't empty - uses Apache Commons Lang.
Validate.isTrue( !pemItems.isEmpty() );

// No support for generics, so have to cast. (Could have cast the entire List)
final PEMItem csrPemFormat = (PEMItem) pemItems.get( 0 );

// Verify the type.
Validate.isTrue( csrPemFormat.pemType.equals( "CERTIFICATE REQUEST" ),
  "This is not a CSR" );

final PKCS10CertificationRequest csr = new PKCS10CertificationRequest(
  csrPemFormat.getDerBytes() );

We first decode the PEM (Base64) CSR into List of PEMItems. Note that Commons-SSL doesn’t support generics, so you are going to get a cast warning somewhere in the code, no matter what. When calling getBytes() on the CSR string, you may want to specify the US-ASCII character set, since the no-arg method uses the platform default character set, which might give inconsistent results across different systems when converting from characters to bytes.

We then grab the first entry in the list, checking if it is a CSR. We can now convert this into the proper data structure by supplying the raw bytes (i.e. the DER-encoded format) to the constructor of PKCS10CertificationRequest.

The method to extract the X509Extensions structure from the PKCS10CertificationRequest is shown below.

   /**
    * Gets the X509 Extensions contained in a CSR (Certificate Signing Request).
    *
    * @param certificateSigningRequest the CSR.
    * @return the X509 Extensions in the request.
    * @throws CertificateException if the extensions could not be found.
    */
   X509Extensions getX509ExtensionsFromCsr(
         final PKCS10CertificationRequest certificateSigningRequest ) throws CertificateException
   {
      final CertificationRequestInfo certificationRequestInfo = certificateSigningRequest
            .getCertificationRequestInfo();

      final ASN1Set attributesAsn1Set = certificationRequestInfo.getAttributes();

      // The `Extension Request` attribute is contained within an ASN.1 Set,
      // usually as the first element.
      X509Extensions certificateRequestExtensions = null;
      for (int i = 0; i < attributesAsn1Set.size(); ++i)
      {
         // There should be only only one attribute in the set. (that is, only
         // the `Extension Request`, but loop through to find it properly)
         final DEREncodable derEncodable = attributesAsn1Set.getObjectAt( i );
         if (derEncodable instanceof DERSequence)
         {
            final Attribute attribute = new Attribute( (DERSequence) attributesAsn1Set
                  .getObjectAt( i ) );

            if (attribute.getAttrType().equals( PKCSObjectIdentifiers.pkcs_9_at_extensionRequest ))
            {
               // The `Extension Request` attribute is present.
               final ASN1Set attributeValues = attribute.getAttrValues();

               // The X509Extensions are contained as a value of the ASN.1 Set.
               // Assume that it is the first value of the set.
               if (attributeValues.size() >= 1)
               {
                  certificateRequestExtensions = new X509Extensions( (ASN1Sequence) attributeValues
                        .getObjectAt( 0 ) );

                  // No need to search any more.
                  break;
               }
            }
         }
      }

      if (null == certificateRequestExtensions)
      {
         throw new CertificateException( "Could not obtain X509 Extensions from the CSR" );
      }

      return certificateRequestExtensions;
   }

Basically, we get the certificate request info from the CSR structure and then extract attributes from it. Then, we loop through to find the attribute with the “Extension Request” OID.

After that, I make an assumption that the actual extensions are contained in the first value of the place of the ASN.1 Set that makes up the “Extensions Request” structure – not a big assumption, and in my testing I haven’t encountered a situation where this wasn’t the case. It’s worthwhile to keep in mind that ASN.1 often prescribes Set or multi-value structures in places where the underlying data can only be single-valued.

After running through that code, we’ll have either found the extensions, and be returning them in a X509Extensions structure, or an exception will be thrown. You could modify the code to return null if that suits your style or purpose better.

A few more notes

Once you have the X509Extensions structure you can use the extensions contained within to create/issue a certificate with them. Check out the Bouncy Castle Guide on Certificate Generation for more details.

Note that a CA is not required to use any of the extension requests present in a CSR – hence the name “requests”. It is entirely up to the CA to decide what extensions are appropriate, along with their values, for the certificates that it issues.

Code Review

The code is a little complicated and could probably benefit from some refactoring. However, a lot of the complexity derives from the fact that the X.509 and associated standards are quite complex themselves. This is a reflection on the vision that the designers of X.509 had for the future of the standard. However, the complexity of X.509 is another topic for another article.

I hope you found this article useful, as while I found lots of information for generating CSRs, information on parsing and working with them was a little sparse. Please feel free to leave your comments below!

This is why inheritance in JavaScript is probably one of the least understood concepts. While languages like Java have well-defined constructs for inheritance, the topic is of less importance with JavaScript. In many situations, you’ll never have to deal with these aspects when programming in JavaScript, simply because it isn’t required for a lot of client side scripts. However, for larger-scale web applications, applying object-oriented principles to your code may make it easier to design, improve and maintain.

There have been many articles written about inheritance in JavaScript and how it can and should be done. You really don’t need to read mine to gain an understanding. Rather, I’m just going to write about what I’ve learned, the process I went through and the experience I’ve gained along the way.

It’s all new(s) to me

If you come from a Java background, you’ll be no stranger to the new keyword. Using it allows you to instantiate a new instance of an object from its class by calling its constructor. The keyword also makes a lot of sense, since you’re creating a ‘new’ object.

JavaScript also has a new keyword, but it doesn’t do quite the same thing as its Java counterpart, though at first the effects might seem similar. This is one of the main reasons why JavaScript inheritance tends to be poorly understood.

Consider the following example.

function Foo(name)
{
  this.name = name;
}

var fooObject = new Foo('I am foo');

If you’re familiar with Java or JavaScript, this example is fairly straightforward. In the prototype-based JavaScript, functions can serve as object constructors in somewhat the same manner as a constructor in Java. However, Foo in the above example is not a class, since classes do not exist in JavaScript. So, if Foo is not a class, what exactly happens when the statement var fooObject = new Foo('I am foo') is executed?

Taking a step back

Before we dive into the details, I’ll explain the concepts of a prototype-based language as it applies to JavaScript. I mentioned above that JavaScript does not use classes like Java does. This basically means that new objects are not created from instantiation of classes, but rather inherit from existing objects. Thus, there is no “class hierarchy” but rather just an object hierarchy.

In JavaScript, all objects are descended from the built-in Object type. This is similar to how all Java classes implicitly have the Object class as a superclass. In JavaScript, instead of extending classes, you can inherit by manipulating the prototype property on a type; that is, the prototype property on the function you are using to create an object. Let’s see some code to straighten things out.

function Foo(name)
{
  this.name = name;
}
Foo.prototype.getName = function()
{
  alert(this.name);
}

var fooObject = new Foo('I am foo');
fooObject.getName(); // Will alert with 'I am foo'

This example is identical to the first one, except for the lines that are emphasized. Here, I’ve set the getName property on the prototype property of Foo equal to a reference to a Function object. This is effectively the same as defining a method for a class, since any object created from that type can call the method getName() on itself to return the proper value. But what exactly is happening, and what’s the deal with the prototype property?

More new(s)

In JavaScript, the new keyword actually accomplishes a few things. When you execute an expression such as var fooObject = new Foo('I am foo'), here’s exactly what happens.

1. First, a new generic object is created. This object is the same as if you created the object using the statement new Object(), using JavaScript’s built in Object type.
2. The constructor function, that is, the function Foo(), is then called with the this keyword set to reference the newly-created object. The parameters supplied are also passed to the constructor function, in this case, the string “I am foo”. If you’re familiar with context, this is equivalent to:

   var fooObject = new Object();
   Foo.call(fooObject, 'I am foo');

   Thus, the code in Foo() sets a property called name equal to the supplied string. Up to this point, things are the same as if you had created a new object and then manually set the name property yourself. The next step is where things change.

3. The last step is where inheritance takes effect. The constructor function, in addition to executing the specified code above, also sets an internal property called __proto__ equal to the value of Foo.prototype. This is how the new object inherits from the old one.

   When you call a property on fooObject now, JavaScript will first check to see if the object has a local value for it. In this case, the only local property is name. (Besides the internal and implicitly set __proto__ property) However, if it does not exist locally, it will check to see if the property exists under the object referenced by the __proto__ property. In this case, the getName() method exists under here.

Where things get confusing is because of how the new keyword is used. Perhaps the designers of JavaScript wanted to use a keyword familiar to Java programmers so as to ease the transition to a new language that sounded so similar. While it accomplishes a similar goal and for the most part you can consider the action to be almost the same, the use of the new keyword conceals the true meaning of prototype-based inheritance in JavaScript. This ends up causing more confusion when you start digging into code.

We’re all the same

Suppose you created multiple objects from the Foo() constructor, called fooObject1, fooObject2 and fooObject3, In one fell swoop, you could add a new method to all of these objects without having to recreate them. This is because of the prototype property. Because each object contains a reference to Foo.prototype, adding a new method here will allow all objects access to it. For example:

Foo.prototype.yellName = function()
{
  alert(this.name.toUpperCase());
}
var fooObject3 = new Foo('I am Foo 3!');
fooObject3.yellName(); // alerts 'I AM FOO 3!'

This adds another method to all Foo-constructed objects allowing them to “yell” their names.

Extending Types

I mentioned inheritance above but with just one type definition, the principles weren’t too clear. Suppose we decided to extend our Foo “class” – how exactly would this work? First, you need to define the child type and then set its prototype value to a new object of the parent type. An example:

function FooChild(childName)
{
  Foo.call(this, 'I am a child of Foo and my name is ' + childName);
}
FooChild.prototype = new Foo('');

var fooChildObject = new FooChild('Barbar');
fooChildObject.getName(); // Will alert with 'I am a child of Foo and my name is Barbar'

Let’s break down what’s going on here.

1. First, we define a new constructor called FooChild. In it, we call the parent constructor function with the context set to the current object. This allows the name property to be set on the object during creation since that’s what the parent does.
2. Then, we set the prototype property equal to a new object that’s an instance of Foo. This is what allows all of the child objects to have access to the parent’s properties, such as the getName() method. Coming from the Java world, this would be roughly equivalent to the extends keyword, when defining a class that inherits from another.

A few more details

JavaScript provides two special operators for dealing with types and objects. One is called instanceof and the other is typeof. The latter, typeof, is less useful since it only deals with built-in JavaScript types.

The typeof operator returns the current variable’s type, but is limited to predefined types. For example, typeof fooChildObject or typeof fooObject both return a string with the contents of “object”. Thus, differentiating between the two is impossible. More information can be found at the Mozilla Developer Center.

The instanceof operator is more interesting. It takes two arguments and tests whether the first is an instance of the second. (I guess I didn’t need to explain that) For example:

function Foo(name)
{
  this.name = name;
}
Foo.prototype.getName = function()
{
  alert(this.name);
}

function FooChild(childName)
{
  Foo.call(this, 'I am a child of Foo and my name is ' + childName);
}
FooChild.prototype = new Foo('');

var fooObject = new Foo('I am foo');
var fooChildObject = new FooChild('Barbar');

alert(fooChildObject instanceof Foo); // true
alert(fooObject instanceof Foo); // true
alert(fooChildObject instanceof FooChild); // true
alert(fooObject instanceof FooChild); // false;

In the above code, it is clear that fooChildObject is an instance of FooChild, and fooObjectis an instance of Foo. However, fooChildObject is also an instance of Foo, since its type was inherited from it through the prototype property. However, fooObject is not an instance of FooChild since that type is a child of Foo.

I hope I haven’t said “foo” one too many times for you.

More information about instanceof is again available from the excellent Mozilla Developer Center.

Concluding remarks

I hope this has helped you to understand the nature of JavaScript’s built-in inheritance features. I know I found it very convoluted at first, coming from a class-inheritance background. I read everything I could find on the subject, and I believe it’s made me a better JavaScript programmer by understanding some of the “inner workings” of the language. I encourage you to check out some of the references I’ve provided below.

References

1. Prototypal Inheritance in JavaScript – Douglas Crockford
2. The Philosophy of JavaScript – Jesse of 20bits
3. Prototype Inheritance Revisited – Mozilla Developer Center
4. The Employee Example – Mozilla Developer Center

I won’t go into too much detail about the features since I wanted to talk about integrating the Eclipse plugin Mylyn with a Trac setup on Assembla. There can be some issues getting things to work so I’ve outlined what I did to get everything running nicely.

Background: Mylyn

Mylyn is an excellent task-management plugin for the ultimate IDE, Eclipse. I have been trying it out for a variety of things, since I was trying to find something better than just text files for managing various tasks lists. However, Mylyn does much more than just task management as it helps to streamline your work environment with “context”. I haven’t started using these advanced features though, but what really caught my eye was the integration Mylyn offers with various issue-tracking services such as Bugzilla and the aforementioned Trac. This is accomplished by various “connectors”, with each connector being specific to one of the issue-tracking systems.

The Problem: XML-RPC Integration

Integration of Mylyn with Trac allows you to view, create and edit tickets in a Trac repository from within Eclipse. To accomplish this, there are two levels of integration, the first being simple web-based access. This is the more primitive of the two and has been around for longer. Basically, items are still edited from a web browser; the only difference is the web browser is spawned within Eclipse. This isn’t really ideal and doesn’t offer a real integration.

The second uses an XML-RPC interface to send/receive data and thus offers proper integration with the Eclipse environment. However, when trying to connect to my Trac setup on Assembla with this choice, I ran into a lot of intermittent 404 (not found) errors. Basically, synchronization was very flaky and by no means usable.

The Fix

I did some searching and found this page on the Assembla site where other users had experienced the same problem. Scrolling through the comments brought me to this nice fellow’s explanation of the problem, where a screencast was provided showing how it had been fixed.

Basically, these are the steps I did to get Mylyn XML-RPC integration with Trac working.

1. Enable the XML-RPC plugin

   Go to your Trac site, then click on Admin. On the left sidebar go to General > Plugins. There should be a section called TracXMLRPC; click to expand it. You might as well enable RPC access for all of the options provided, though I’m not sure if this is necessary. Here’s a screenshot.

   

2. Enable XML-RPC permissions

   After that, you need to enable permissions for XML-RPC access. Go to General > Permissions on the sidebar. In the “Grant Permissions” area, add a permission for “XML_RPC” for “@editors“. Using “@managers” for the subject might also work/be needed if you’ve setup access for those users. This is the basically what it should be:

   

3. Ensure there is at least one ticket in the system

   For some reason, I had weird errors when trying to synchronize/connect to a Trac repository with no tickets. This was corroborated by the fellow who originally found the solution to this problem. It’s a minor issue though, just click “New Ticket” and create a placeholder.

4. Add Trac to Mylyn

   This step’s simply enough; though some suggestions recommended using http://<domain_name_to_assembla_trac>/<space_url_name>/login/xmlrpc as the URL, I simply used http://<domain_name_to_assembla_trac>/<space_url_name> and it worked fine. Remember to use XML-RPC as your access type or you won’t get proper integration.

   

After that, you should be able to properly connect to your Trac repository using the XML-RPC option of Mylyn. Then, you can finally enjoy proper Trac integration in Eclipse!

You may have run into this particular aspect of JavaScript when working with event handlers. For example:

function alertId()
{
  alert (this.id);
}

document.getElementById('someId').onclick = alertId;

This will return the “id” attribute of the element that the function has been attached to. You could attach the same function to multiple objects and each time you called it on a different object, it would return a different value, since the context is different. (Minor note: using element.attachEvent(), as part of the Microsoft event handler model, does not change the context of the function so “this” will still refer to the window object)

However, there may be times when you want to change the meaning of this without actually having to attach that a function to an object. Using the call() and apply() methods of the Function object can allow you to do this.

Context is everything

Let’s backtrack for a moment. In JavaScript, many (but not all) variables are objects. This includes the references to all functions as well – they are also objects. In the example above, using “alertId” (without the parentheses) would refer to the Function object that represents alertId. As the Function object is a predefined object in JavaScript, it has methods and properties associated with it.

Two of these methods are call() and apply(). Using these methods on a Function object allows you to set the context of that function – that is, what the “this” keyword refers to. The two only in how arguments are passed to the function whose context is being redefined. For example apply() takes an array of arguments like this:

function someFunction(arg1, arg2)
{
  this.id = arg1 + arg2;
}

var arrayOfArguments = ['valueOfArg1', 'valueOfArg2'];

someFunction.apply(objectToBeUsedAsThis, arrayOfArguments);

The values in the second-argument array are then used as the arguments to the someFunction() function.

The call() method is almost the same except it does not take an array of arguments, but rather just an indeterminate number of arguments that are all passed to the function. For example, the above could also be accomplished with this code:

function someFunction(arg1, arg2)
{
  this.id = arg1 + arg2;
}

someFunction.call(objectToBeUsedAsThis, 'valueOfArg1', 'valueOfArg2');

I prefer to use apply() sometimes since you can directly use the arguments variable that is local within all functions. (The variable arguments stores all the arguments that were passed to the function when it was called, and so this can be used in a situation with where it is desired to have a function with a variable number of arguments.)

A useful example

So far, the examples posed have been fairly trivial. Let’s look at a real-world use of call() to illustrate its usefulness. Remember the arguments variable? Basically, you have access to this object variable whenever you’re inside a function since it stores all the arguments passed to this function. However, it’s not exactly an array (although it works like one sometimes) and thus it does not have access to Array methods such as join().

We could easily convert it into an array by accessing each property by its index using a loop, but there’s an easier to way to do this. Consider the following code:

function someFunction()
{
  var argsArray = Array.prototype.slice.call(arguments, 0);
}

Using this one line, we have successfully converted the arguments into a true Array object and stored the result in the argsArray variable. How? First, we access the slice() method on the Array object through the prototype property and then call() the method telling it to use the arguments object as this.

The slice() method allows us to extract a section of an existing array. However, by using call() we are able to apply its effects on the arguments object that is similar to, but not exactly an Array object. The second argument of ’0′ merely indicates that we want to extract not just a part of arguments but all of it. Since slice() always returns an Array object, we thus get back a true array containing the same data as the arguments object. And that’s it!

Note that the above example could be compacted even further. However, it looks very cryptic and can be confusing. (As if the previous example wasn’t confusing enough!)

function someFunction()
{
  var argsArray = [].slice.call(arguments);
}

This example works the same as the previous one. Instead of using Array.prototype, we create a ‘dummy’ empty array to get access to the slice() method. The second argument of ’0′ isn’t needed, as if it is left out when using slice() the entire contents will be returned.

Contextual Conclusion

In short, using these methods to change the scope of a function can allow you to do some neat things with JavaScript that aren’t possible in some other languages. However, one should always be mindful to keep code readable and maintainable and to lessen the learning curve for those new to a language.

Some of this may have transferred over to JavaScript, a language that is already poorly understood and often implemented even worse. It is often hard to find well-written, maintainable JavaScript code, as it is often left as an afterthought in a project or otherwise not given much consideration, having been delegated to the realm of popup scripts and mouse-overs. While exception handling may be overkill for a lot of JavaScript applications, many do not even know of JavaScript’s exception-handling capabilities. In this article, I’ll give a brief overview of exception handling and some recommendations on how to use it in JavaScript to improve the readability of code.

Exceptional conditions

I won’t go too in-depth about the merits of using exception handling but will instead just give a brief overview. (While there are some drawbacks, these apply more to the Java language rather than JavaScript)

The main reason for using exceptions is to have a separate channel for communicating errors. Without this, you must communicate error conditions using the function itself. Consider a function that performs mathematical division:

function divide(dividend, divisor)
{
  var quotient = dividend/divisor;
  return quotient;
}

Division is a fairly simple arithmetic operation, but of the four basic operations it is the only one that has limits on its arguments: the divisor (the term you divide by) cannot be zero, since division by zero is undefined. So, how should you handle cases where the supplied arguments result in division by zero? (The situation is very likely in an application accepting user input)

Without using exceptions, you have a few options, each of which has its own weaknesses. Firstly, you could choose not to return anything and just alert() the user of the error. This isn’t good since when you call the divide() function, you expect a result, not a warning message.

Secondly, you could choose to return a special “error code” indicating that there was a division by zero. But this creates another problem – what exactly do you return when something goes wrong? In this case, the only error case is division by zero – since JavaScript is a weakly-typed language, you could just return false on this error, but then in the calling code you’d have to check if divide() equaled false before using it, probably using the strict equality operator. As you can see, things get messy fast.

Alternatively, you could just check the inputs/arguments every time before you called the function. However this is clumsy, and adds another layer of complexity where something could go wrong.

Another way of doing things

As mentioned before, exception handling adds a side channel of sorts strictly for communicating errors. By doing this, it allows for the interruption of program flow for the purpose of dealing with the exception or error situation. Using exceptions, you would re-write the function above like this:

function divide(dividend, divisor)
{
  if (0 == divisor) {
    throw new Error("Bzlorg! Cannot divide by zero.");
  }

  var quotient = dividend/divisor;
  return quotient;
}

Here we are checking if the divisor equals zero – signifying an invalid input value – and then throwing an exception if this is the case. How is this different than returning an error code?

The main difference is in the control flow of the program; using exceptions causes a change in the program flow. In the above example, if the divisor equals zero, the execution of the function stops there and returns to the calling code with the throw exception. The subsequent statements calculating the quotient and returning will not be executed. Here’s an example of how you’d call the divide function.

try {
  var dividend = 3;
  var divisor = 0;

  var quotient = divide(dividend, divisor);

  alert("The answer is " + quotient);
}
catch (e) {
  alert(e.message);
}

With exceptions, you enclose code that could throw an exception with a try block. This signifies to the interpreter (in the case of JavaScript) that you will be executing code (in this case, calling a function) that could throw an exception as a result of some error condition. Thus you are trying to do something – but as in real life, things may go wrong.

In this example, everything works until the line calling divide. Since divide throws an exception with the input values supplied, flow will be directed to the catch block. All try blocks must be followed with a catch block, with the variable in the parentheses specifying the variable to hold the thrown exception object. In the code above, we merely alert the user to the problem – the message “Bzlorg! Cannot divide by zero” is displayed – in a real program you most likely would want to do handle the error differently depending on the context – but that’s a whole different topic.

If, however, you executed the code with valid values and no exceptions were thrown, once the program had got to the end of the try block it would jump over the following catch block and the user would be alerted with the correct answer. Code within a catch block is only executed in the event that an exception is thrown.

Differences with Java

Since Java is an extremely popular language and one that also uses a similar exception handling model, it would be prudent to discuss some of the differences and similarities with it and JavaScript.

1. No multiple catch blocks with JavaScript

   This is perhaps the biggest difference. If you’re familiar with Java you’ll know that different exception objects can be thrown during execution (all subclasses of the root/parent Exception class defined by Java), each signifying different error conditions. You catch each of them separately by using separate catch blocks, each specifying a particular class or parent class. However, with JavaScript, as you might have noticed from the code above, there can only be one catch block and thus there’s no need to specify the exception class.

   If, however, you want the granularity of working with different exception classes, you’ll have to use the instanceof operator within a catch block, like this:

   try {
     ...
   }
   catch (e) {
     if (e instanceof RangeError) {
       ...
     }
     else if (e instanceof TypeError) {
       ...
      }
   }

   It’s not as elegant as having multiple catch blocks, but it’s one way to deal with multiple exception types.

   Correction:

   It appears I was mistaken. In JavaScript, you can indeed have multiple catch blocks, as seen in the Core JavaScript 1.5 Guide from the Mozilla Developer Center. My initial example above is still valid syntactically, but this way may be more appealing. An example is as follows:

   try {
     ...
   }
   catch (e if e instanceof RangeError) {
     ...
   }
   catch (e if e instanceof TypeError) {
     ...
   }
   catch (e) {
     // General catch-all block.
     ...
   }

   It just goes to show that when you think you know something, you probably don’t! This is part of why I like JavaScript (and by extension, programming); there’s always more to learn and experience to be gained.

2. Exception types

   The discussion of exception types brings us to another point – the different exception types in JavaScript. JavaScript defines some built-in exception types, all based off the parent Error object. These should suffice for most situations where you’re checking user input (the most common use), but if you’re developing a complex application you may want to define your own.

   In that situation, things get a little tricky, especially if you’re coming from Java. Despite the outward similarity, JavaScript does not uses classes like Java, but instead uses a prototype-based approach where inheritance comes from existing objects. In this respect, things can get complicated as there are debates on what the best way to inherit from objects is and to that degree, a few JavaScript libraries have been written to facilitate the extending of objects in JavaScript. These points are beyond the scope of this article, but I thought I’d just point you in the right direction.

   Interestingly, you can also throw many different types of expressions, and are not limited to the built-in exception types. For example, throw false; and throw "Hello World"; are valid statements, but in my opinion, it doesn’t make much sense to throw any type of expression just because you can. Using the built-in exception types (or defining your own) is a better practice, though throwing just String expressions might be alright in some situations.

3. Runtime errors

   During execution, you code may trigger runtime errors within JavaScript – for example, when trying to reference a property on a non-existent object. These will also result in a new Error object being thrown, even though you did not define this throw in your code. If this happens within a try block, the exception will subsequently be caught in the following catch block, and if you’re not expecting this error you may miss it. (If, for example, you’re only looking for specific exception object types)

   This can create problems with some of the JavaScript debuggers out there like Firebug. Since the runtime exception is being caught, Firebug will not be able to catch it (it is prevented from “filtering” up), so you may not be able to locate the source of your error if you’re relying on the debugger.

   My recommendation is thus to ensure your code runs properly under normal conditions. Only then should you start using exceptions and try-catch statements. This will ensure that no unexpected runtime exceptions get caught. (The runtime errors are analogous to the unchecked runtime exceptions of Java in that they are not normally caught)

Summing it up

The whole point of using exceptions is not to make your code “work” better – anything that can be accomplished with exceptions can most likely be done without it, with just the same end result. The point is to make your code more readable, manageable and flexible. By using exceptions you get rid of having to use cumbersome “error codes”, the values of which you may forget later. You also get more flexibility with how you handle errors. You need not handle the error right in the function where it occurs – you can throw an exception to the calling code and handle the error there – or, alternatively, you could let the exception bubble up to a higher-level and handle all errors there. It really depends on your needs, but using exceptions allows for this to be implemented more readily.

Though exceptions may seem like overkill for JavaScript and despite the limitations of its exception handling model as compared to that of Java’s, there are still some benefits to using exceptions, especially for complex JavaScript applications that you may implement to improve the interactivity of your site.

Changes/Fixes

• 2007-12-06: Changed throw new Exception(...) to correct statement of throw new Error(...).
• 2008-01-08: Fixed incorrect assertion of “No Multiple Catch Blocks” in JavaScript; added remarks about being able to throw any type of expression.

SpeedFan is a great utility for enthusiasts who’ve built their own PC. Besides being able to show the temperatures inside your system (from various sensors in the CPU, motherboard and HDDs) and other vitals such as voltages and fan speeds, it can also automate the cooling cycles of your machine. As its namesake implies, SpeedFan is able to automatically control your computer’s fan speeds based on the temperatures reported by various hardware sensors. This can allow you to find the right balance between a cool system and a noisy one. However, it does require some configuration, as I’ll attempt to show you in the following article.

It’s all in the details

All the material I’m about to present here is available in the help file for SpeedFan, however, since most people use the Internet for everything, myself included, I thought I’d summarize the most important points. SpeedFan has a lot of functionality and it’s easy to get lost in all of that when all you want is something simple like automatic fan control. (Some motherboards already support this, but SpeedFan brings this functionality to almost any motherboard that’s reasonably new)

First and foremost, the fans that you want to control must be plugged into one of your motherboard’s 3-pin fan headers; they cannot be plugged into 4-pin molex connectors that come straight from your power supply. This is because SpeedFan controls fan speeds’ by varying the output (using PWM) of the 3-pin fan headers on your motherboard. If you want to control the speed of your 4-pin fans, you’ll have to use some sort of fanbus or external fan controller.

Getting started

On the main SpeedFan window, you may have noticed a checkbox for “Automatic fan speed”. However, checking it is not enough to properly set it up, though it would be nice if things were this easy! For now, you can check it, but nothing will happen – you shouldn’t notice any change in your fans’ speeds.

Click on “Configure” to bring up the options window. SpeedFan is a fairly powerful program, but that means configuration is required to make it do what you want. The assumption that SpeedFan uses is that various temperatures can be influenced by the various fan speeds in your system. You need to define these relationships. For example, in my system “Temp1″ is the CPU temperature. (I haven’t bothered to rename the labels) In the screenshot below, I have linked it with “Speed01″ and “Speed02″, which correspond to my CPU’s fan and a case exhaust fan.

This tells SpeedFan that it should vary these fan speeds based on the temperature they’re associated with. You also need to configure threshold temperatures; there are two, “Desired” and “Warning”. The desired temperature tells SpeedFan what it should aim for. Once the desired temperature is reached, SpeedFan will begin to drop fan speeds down to some minimum you specify; if the temperature is above desired fan speeds will increase by an amount related to how much the temperature is above the desired. Once the temperature reaches the warning value, fan speeds will be set to maximum. (100%)

We now need to configure each of these fans. Go to the “Speeds” tab (not the “Fans” tab) of the configuration and you’ll see a window like this:

Remember that Speed01 and Speed02 are linked with the Temp1. Here is where we define the minimum and maximum fan speed values. When the temperature is at or below desired, the lowest the Speed01 will go is 30%, while the maximum I’ve specified is 100%. This range is for temperatures up to the warning value. When the temperature is at or above warning, the fan speeds linked to it will be set to 100% regardless of what you’ve define the maximum to be. This is a sort of fail safe to prevent overheating – better safe and noisy than silent and sorry. Also important to note is that you must check “Automatically variated” for each fan you want to automatically control. (This is separate from the main automatic fan speed checkbox on the main SpeedFan window we saw earlier)

You may need to experiment to find out what are the best values for minimum and maximum fan speeds. Also, some fans fail to report their rotational speed (RPM) when spinning slower, so you may get a reading of “0 RPM” within SpeedFan. You’ll need to actually check whether this is the case.

One last thing you may want to configure is how fast SpeedFan will begin to adjust fan speeds when it has to respond to a temperature change. This is accomplished by setting the “Delta value” on the Options tab of configuration:

This sets the step-size (in percent) for fan speed changes. With a larger value, SpeedFan will adjust fan speeds more quickly since it will be increasing or decreasing by that amount each time. Experiment to find what works best. I’ve found that with too large a step/delta size, temperatures and fan speeds will oscillate – basically the fans will speed up too fast, causing the temperatures to drop, which in turn cause the fans to slow down too much, which then causes temperature to rise again, completing the cycle. If you’ve taken a course in control theory you’ll realize that this is perhaps the classic example problem in control theory. (By adjusting the delta value I believe you’re adjusting the proportional value of the controller – though I am not sure if SpeedFan implements a full PID controller)

Lastly, you may want to check “Set fans to 100% on exit” just in case you accidentally shut down SpeedFan – this is another protective feature.

Finishing up

Click “OK” on the configuration page to save your changes, which should bring you back to the main window. Then, make sure “Automatic Fan Speed” is checked here, and your system should now be set up for automatic fan control! I have been using SpeedFan for a few years and wasn’t aware of this functionality until recently. Just goes to show that you can always learn new things!