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.

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!

I recently got a new Wireless-N router (based on the Draft 2.0 of the 802.11n spec.) to replace my old, but trusty WRT-54GL, an 802.11g router. I bought this router just over a year ago to replace another 802.11g router that was acting up. I specifically bought the WRT-54GL (as opposed to the regular WRT-54G) because I knew that I’d eventually want to flash it with third-party firmware. (The WRT-54GL runs on Linux and has better hardware than later versions of the WRT-54G)

I recently got my Xbox (with XBMC) setup in my living room. This placed it far away from the wireless router in my apartment and not wanting to run an unsightly CAT-5 cable around my place, I decided that I’d need a wireless bridge since the original Xbox does not have a built-in wireless adapter. (Nor does the 360, I believe). A quick look around the web showed that most dedicated wireless bridges were quite expensive and of dubious quality. Since I already had the spare WRT-54GL, I decided to flash it with DD-WRT, one of the most popular third-party firmware replacements, and see how it would function as a wireless bridge for my XBMC setup.

Bridging the gap

A wireless bridge (depending on your definition) is a device that allows regular wired clients access to the network over a wireless connection. This was exactly what I needed for my XBMC-equipped Xbox. This would give XBMC access to the network and allow me to play content/videos stored on my PC using XBMC, effectively turning it into a streaming box. Doing a little research, I found out that wireless bridge capabilities were one of the many features that the DD-WRT firmware added to the WRT-54GL.

Mind you, DD-WRT doesn’t only work with the Linksys WRT-54G/GL. A full list of supported devices is available on their site, and the list is quite long. However, I believe the WRT-54G was the first, after people discovered that initial versions of the WRT-54G were running Linux, thus requiring Linksys to make the source code available and spawning a bevy of third-party development for the device. (Some later versions of the WRT-54G unfortunately do not support the full version of DD-WRT since the newer WRT-54Gs are now being shipped with VxWorks, another embedded OS, instead of Linux and thus have different hardware configurations)

Getting it to run

DD-WRT has a feature list so long that covering it is outside the scope of this article. Instead, I’ll focus on how I set it up as a wireless bridge to provide wireless access to the network for wired clients. The DD-WRT wiki has an installation guide, and while it gets the job done, it’s unfortunately very convoluted, confusing and contradictory, on account of it being written wiki-style by many authors with evidently no editing whatsoever.

Basically, here’s what I did to get my WRT-54GL flashed to DD-WRT from the regular Linksys firmware: (As adapted from the installation guide, which you may want to follow as well) If you do not have another router to use while you’re flashing, you’ll definitely want to read through the instructions thoroughly before doing anything to make sure you have all the required materials, instructions and so forth, since if anything goes wrong, you won’t have an Internet connection!

1. Make sure you are on a wired connection to the router.
2. Reset it to factory defaults.
3. Download the latest stable MINI version of DD-WRT. Flash using the “generic” bin over the web console. The guide recommends using Internet Explorer instead of Firefox and while those instructions may be outdated, I followed them anyways.
4. If, after flashing, you cannot login with the default root/admin (which happened with me), do a hard reset of the router. This is accomplished by holding down reset and plugging in the router while continuing to hold reset for 30 seconds. (You may just have to hold reset for 30 seconds without the plug-in procedure) This should reset the login/password back to the normal defaults
5. Now, get the latest stable STANDARD version of DD-WRT. Flash again using this version’s “generic” bin over the web console. This adds more features over the mini version, which apparently you must first flash with when changing from the default Linksys firmware.

This procedure worked for me, but I can’t be sure it’ll work the same for every router out there.

Getting the wireless bridge connected

The documentation for this over at the DD-WRT site, while long, is less confusing than the installation instructions. I basically followed them to the letter, and within a few minutes, the WRT-54GL was online and connected over a WPA-PSK secured wireless connection. I definitely recommend some form of WPA over WEP, as WEP is broken and cannot be considered secure for anything.

The guide indicates that WPA2 does not work correctly for the current version of DD-WRT (2.3 SP2 as of this writing), though it is an option in the settings for a wireless bridge. I have not tried to get WPA2 to work myself, but reports from others seem to indicate that it does not work. If and when I do try, I’ll update this article with my results.

Well, that’s about it. I’m now happily streaming video to my XBMC setup, and so far, the wireless connection has been rock solid, without a single drop-out, freeze-up or slowdown. In fact, it feels as zippy as a wired connection! This is what wireless networking should be like and I’m glad it’s finally becoming a reality.

I’ve had a Logitech G15 gaming keyboard for over a year and a half already, and it’s pretty much been the best keyboard I’ve ever used. While it can’t compare to my old Fujitsu 4725, a “clicky” keyboard, in terms of tactile response, it’s built-in LCD and extra gaming macro keys put it on top in terms of usefulness. The LCD even has its own set of buttons for controlling programs or applets that are running on it.

Logitech bundled several applets with the G15 for displaying things like volume, resource usage and a clock. However, these things were on different screens, so if you wanted to see the clock you’d just have to wait for it to appear in the cycle, or else navigate to it using the buttons. This was annoying, and I ended up not really utilizing the screen to its full potential. That is, until I discovered SirReal’s multipurpose G15 plugin. This is the only G15 applet you’ll ever need. Please check out the screen shots and read more, and I guarantee you’ll love it.

Searching for the killer applet

I’d previously played around with G15 applets found at sites like G15 mods and G15 Forums, and while some of them were nifty, I couldn’t really find any that suited my needs. Some of them additionally required LCDStudio, another program, to run - which added more resource usage, something I was trying to avoid. I never really used the LCD for games, such as viewing status/ammo/info, which I guess is the intended usage, judging from Logitech’s marketing, so this ability did not matter to me.

So, what I really wanted was a multipurpose applet/utility based on Logitech’s SDK, so that it would run just using Logitech’s LCD Manager. This would eliminate the need to have separate LCD applets for each bit of info I wanted to see, and would simplify the display - no more having to cycle through multiple pages.

SirReal’s G15 plugin cometh

SirReal’s Multipurpose G15 plugin fit the bill. (Another link) This applet crams an astounding amount of information, almost everything you could want, into the G15’s 160 x 43-resolution LCD. The plugin is fully-configurable so you can define what and where you want to display certain modules of information. Here’s a shot of what mine’s currently displaying:

Along the top, we have the full date, number of unreal e-mails (displayed as envelopes) and the 24-hr time. The time and date format can be customized. In the next row, resource usage (CPU/MEM) is displayed. The CPU bar actually consists of three separate 1-pixel bars for my system: One for each core, and one for overall usage. To the right of that, the network usage (current KiB in/out) is displayed, using bars and the numerical value.

On the bottom row are four “slots”. These can be configured to display a variety of information from the supported modules of the plugin. I won’t repeat all of the features here, but it’s safe to say that most people will be satisfied. I have the a world-time clock in the first, the SpeedFan module (for system temperatures) in the second, speaker/volume information in the third and net-graph utilization in the fourth. Each module itself may have multiple screens of information, and you can cycle between them by pressing the LCD button below it. Furthermore, you can have multiple modules in each slot; just cycle between them by holding CTRL and pressing the corresponding LCD button.

A Power User’s dream

As if all of these features weren’t enough (everything from support of Winamp/iTunes, to SpeedFan and TeamSpeak 2, and even detecting unresponsive programs), the setup is completely customizable by editing a simple configuration file. Instructions are in the file itself, so it’s a no-brainer. Furthermore, the applet is small - less than 80 KiB as of version 2.5, and is taking up less than 3 MiB of RAM after several days of continuous usage. CPU usage is similarly small.

There’s simply no reason not to get this applet for your G15 keyboard - it’ll easily replace every other applet you’re running and more. SirReal’s G15 plugin seems to have been made by a true power user, who knows what other power users want from the G15 LCD - an easy to read screen that displays all the useful information you need, from the date/time, volume, CPU/Mem usage and more. It’s truly the uberOptions of the G15 LCD.

Introduction

I originally wrote a short blurb about using uberOptions and SetPoint to get more out of your Logitech mouse, but decided to turn it into a longer guide with more information; uberOptions is a neat program that modifies some of SetPoint’s configuration files in order to allow all application-specific settings for many more Logitech mice than just a select few, and allows for almost any option or command to be assigned to any mouse button, and thus makes it possible to customize your mouse much more.

A lot of people might be wondering what all this fuss is about. Most people don’t have a mouse with more than three buttons (the standard left/right and wheel configuration), and most won’t care for or need one. But, for the rest of us, mostly tech-saavy people who enjoy and use their computer a lot, having a mouse with extra buttons can be a useful time saver, akin to learning keyboard shortcuts.

What’s wrong, then?

SetPoint does an alright job of allowing customization of your mouse. Most of the buttons can be bound to a range of options, but some buttons are limited to certain functions. Furthermore, most Logitech mice don’t “support” application-specific settings through SetPoint - so once you bind actions to certain buttons, they persist no matter what program or game you are using, thus limiting the mouse’s functionality since different programs or games might use different keystrokes or actions. However, this is an intentional software limitation, not a limitation of the mice themselves. For example, the G7, G5 and MX610 mice from Logitech will have application-specific settings available, but other mice, such as the MX1000 won’t have this option available.

To me, this sort of intentional limitation is mind-boggling - but perhaps it’s part of Logitech’s market strategy to set apart certain mice as having “features” that others do not. Or, perhaps they have just forgotten to update their SetPoint software, but I find this hard to believe.

Solution: uberOptions!

Thankfully, a nice fellow by the name of Richard Lowens has written a nifty program, called uberOptions, that changes the configuration files of SetPoint to enable all of the “disabled” options for almost all Logitech mice! Since all this required was modifying some XML files that stored the configuration information for each mouse (and thus determined which had application-specific settings and so forth), once the program has been installed, it doesn’t need to be run again. Thus, you won’t have another program that must always be running in the background, which should cut down on system resource usage, if you’re concerned about that sort of thing. It’s thus a fairly elegant solution.

Before beginning, you’ll need to head over to the uberOptions site and download the program - it’s a relatively small download at only 6.3 MB and so shouldn’t take too long. You should also check out the list of mice supported to see if yours is on the list. Most of the Logitech mice with extra buttons are supported, including the popular MX1000 and MX518 mice. The MX610, G7 and G5 mice are also supported, but as mentioned before, they already support application-specific settings, so all you’ll get out of uberOptions is more options for the buttons.

Note that the older MX700 (original Logitech cordless rechargeable) and MX500 mice are not supported, not because uberOptions doesn’t support them, but rather, SetPoint doesn’t support these mice. Someone might be able to write a configuration file for these to enable support in SetPoint, but I’m not sure if that’s possible or whether it’ll happen - for now, you’re stuck using the older MouseWare for these and older Logitech mice. See further down in this guide for more information.

During installation, uberOptions will backup the original configuration files so that if you decide to uninstall, everything can go back to normal. Once that’s done, you can open up SetPoint and begin setting things up. Here’s what it’ll look like. (Using my MX1000 for reference)

You can see that uberOptions is installed, because it appends a “ü” character after the mouse’s name. The options for each mouse button also look slightly different. As you can see, I’ve left almost everything to the default, except for changing mouse buttons 3, 4, and 5 (the middle, back and forward buttons respectively) to “generic” buttons for “All Programs”. As far as I know, Windows XP supports the first five buttons natively, so this is why I’ve set them to generic buttons. This allows them to work just fine in the desktop and in web browsers. The “Back” and “Forward” functionality is especially useful when moving through directories or browsing webpages - I don’t know how I lived without it before!

As you can see, uberOptions enables almost any functionality to be assigned to any button. The sheer number of functions available is astonishing, and almost confusing. While it my seem daunting at first, it allows for full customization of the mouse’s buttons, which you should be able to do, since it’s your mouse anyways. In fact, you’ll probably not want to change most of the default button assignments for “All Programs”, as things can get a little messy. You’ll probably only want to change the button assignments for application-specific profiles, which I’ve been ranting about since the start as being the most useful ability.

That little drop-down box opens up a world of options, customizability and improvements for your Logitech mouse. Basically, you can assign profiles or configurations of buttons to specific programs or games. You can add any EXE file to the list, and when SetPoint detects that executable as having focus (I.E, the application is in the foreground, or you’re playing the specified game), it will use the button assignments you’ve specified for that application or game! This basically allows for infinite configuration possbilities. In the example screenshot, I’ve added Guild Wars to the list, where for that profile, I’ve assigned a bunch of keystrokes to the extra buttons for more functionality for the mouse in that game.

Keystrokes are perhaps the best way to utilize the extra mouse buttons, since most games use keystrokes as input commands of some sort, and using the keyboard for hard-to-remember keystrokes can be hectic in the middle of a game. Note that this may not be necessary for the first five buttons, since if they’re set as regular/generic buttons, they will be detected as such in a game. The other extra buttons (beyond the fifth) cannot be detected in games as “extra buttons” (for example, the application-switch button and tilt-wheel buttons on the MX1000), and can only be used if they’re assigned keystrokes. RPGs are notorious for having a lot of keystrokes and input commands, so using the extra buttons on the MX1000 only makes sense. RTS games can also benefit similarly.

With a properly configured SetPoint and uberOptions, and some adjustment time, your mouse can actually be programmed to do a lot in applications and games!

Drawbacks and other solutions

There are some behaviour quirks. For example, when I set a button to “generic” for “All Programs” and then selected it again in the options, the ability to set a per-application setting for that button disappeared. If the mouse button were set to something else, the application-specific settings (the “Manage Programs…” button) re-appeared. I’m not sure this is a problem with uberOptions, as it could be a problem with the quirky behaviour of SetPoint. I noticed this when I reviewed the MX610, while using it with a non-uberOption’d version of SetPoint. This doesn’t totally prevent you from configuring application-specific settings, as you just have to be careful how you go about things. If anything, it’s a minor annoyance. Maybe it’ll be fixed in a later version of uberOptions or SetPoint.

An alternative to uberOptions is the LogiGamer Mouse profile utility, which works with MX500, MX700, MX310, MX510, MX900 and MX1000 mice. Like uberOptions, it allows application-specific settings for the mice, so it basically offers the same functionality and features. However, it’s a separate program that, as far as I can tell, must be running in the background for your settings to take effect. It also requires SetPoint to be installed, and also requires the .NET 1.1 Framework to be installed, so if you don’t like that idea, uberOptions is probably a better choice. However, if you’re using a mouse that doesn’t support SetPoint, then this program might be your only option for application-specific settings.

Last thoughts

I hope this guide helped in some small way. For most people, spending extra time configuring a mouse and its extra buttons for specific use in certain applications and games is a foreign concept that doesn’t deserve any attention - I can understand that. However, for us gearheads who get some reward from making something work better than it should, customization is something we can’t be without.

References

1. [uberOptions] Enable all options on all buttons in SetPoint (Forum thread)
2. uberOptions homepage
3. MX1000 mouse button issues (Forum thread)
4. Problem with uberOptions and MB 4 & 5 (Forum thread)
5. UberOptions…wow….just wow (Forum thread)
6. LogiGamer Mouse profile utility homepage
7. Enabling all options on your Logitech mouse