I’ve been working with JavaScript lately and it does support exceptions. Many people for various reasons choose not to use them, but I do. If something isn’t right, I might decide to throw an exception. I guess this comes from my .NET background. What’s different in JavaScript from .NET is the absence of preprogrammed exceptions to deal with common problems. For example in .NET there’s ArgumentNullException to be thrown when one of the arguments is unexpectedly null. I created something similar in JavaScript to indicate that not initialized argument is invalid.
The problem comes from the code that verifies if the argument is null or not.
function NoNullArgumentsAllowed( arg1 )
{
if( arg1 == null )
{
throw new ArgumentNullException( "arg1", "arg1 cannot be null." );
}
// Do something useful
}
Repeating this code for every argument in every method where argument cannot be null gets boring fast and if something is boring I am reluctant to do it and try to find ways to make it either less boring or (preferably and) simpler. Refactoring to the rescue!
function NoNullArgumentsAllowed( arg1 )
{
CheckIfNull( arg1, "arg1" );
// Do something useful
}
function CheckIfNull( arg, argName )
{
if( arg == null )
{
throw new ArgumentNullException( argName, argName+" cannot be null." );
}
}
Now whenever I need to check whether argument is null I can just call CheckIfNull. And then it occurred to me. The logic of comparing the argument to null is always going to be the same, so why not attach it to the exception? That’s right, let exception decide for itself if it should be thrown.
ArgumentNullException.CheckArgument = function( arg, argName )
{
if( arg == null )
{
throw new ArgumentNullException( argName, argName+" cannot be null." );
}
}
function NoNullArgumentsAllowed( arg1 )
{
ArgumentNullException.CheckArgument( arg1, "arg1" );
// Do something useful
}
Now in most cases the logic of throwing the exception is specific to the place it is thrown from. Often though it can be simplified to single true/false answer. To decide if the exception should be thrown we can pass boolean value to the exception checker along with parameters to initialize the exception. Just like it’s done in TDD with assertTrue.
ArgumentException.CheckArgument = function( condition, argName, message )
{
if( !condition ) // use condition != true to enforce condition to be of boolean true
{
throw new ArgumentException( argName, message );
}
} function NoInvalidArgumentsAllowed( arg1 )
{
ArgumentNullException.CheckArgument( arg1, "arg1" );
ArgumentException.CheckArgument(
arg1 == expectedValue, "arg1", "arg1 doesn't equal expectedValue" );
// Do something useful
}
This isn’t a big change, but I think following this style of programming will make code cleaner and shorter. With elimination of tedious ifs and throws people should also be more inclined to check that everything is what it is expected to be. In not-interpreted environment (like in .NET) where it’s impossible to modify classes dynamically (well, in .NET 2.0 it’s possible, but I’m not going to go there. It’s not as simple as in JavaScript anyway.) and you don’t have access to the exception class source, requires a different approach. The simplest solution would be to just abstract working with exceptions into a separate class, like so:
internal class Exceptions
{
internal void ArgumentNullException_CheckArgument( arg, argName ){ .. }
internal void ArgumentException_CheckArgument(
condition, argName, message, stackTrace ){ .. }
}
So what’d you think? Can this approach make working with exceptions easier for you? What do (would) you do to simplify exception handling?
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5