An Un-CATCHable Error?

I’ve been using the scripting tools in SSIS for some time, but I came across something today that I can’t quite explain.  I normally don’t posts unresolved problems on my blog, but I’m trying out a strategy suggested by my friend Lee Everest by sharing unfinished work in the hopes that my research and troubleshooting can help someone else.

So here’s the scenario: I’m building an ETL framework using SSIS, which is now three levels deep (envision grandparent, child, and grandchild packages), and I’ve found that I need to be able to pass values from ancestor to descendant packages and vice versa.  While the former is easily done using SSIS configurations, the latter requires a little scripting to accomplish.  Additionally, this scenario requires that the leaf-level packages must be able to be occasionally run atomically as well as within the ETL framework, It was during the testing of those piecemeal executions that I discovered the issue at hand.

Sidebar: If you’re interested in a how-to on passing values from child packages back up to the parent, have a look at this blog post by Steve Fibich.

The Code

So here’s the code I’m using:

In a nutshell, this code will attempt to write to an SSIS variable named LeafLevelConfigSetting.  That variable does not exist in the current package, so the variable by that name must be inherited from an ancestor package.  What I intended to happen is that, if the package is executed by itself, the LeafLevelConfigSetting variable will not exist in the current scope so the LockOneForWrite() method will throw an exception that should be caught by the try/catch block, allowing the package execution to proceed without error.  In theory, because I’m trapping any exception thrown by the LockOneForWrite() method, my script task should succeed even when there is no LeafLevelConfigSetting variable.

The Problem

The package runs fine when executed as part of the larger ETL framework; the LeafLevelConfigSetting variable is supplied by one of the ancestor packages, and the script task succeeds in updating that value.  However, if I execute the package on its own, it fails every time:

The Execution Log reads as follows:

Error: Failed to lock variable “LeafLevelConfigSetting” for read/write access with error 0xC0010001 “The variable cannot be found. This occurs when an attempt is made to retrieve a variable from the Variables collection on a container during execution of the package, and the variable is not there. The variable name may have changed or the variable is not being created.”.

Huh?  That function call was within the try/catch block and should have been trapped within the script task without causing a failure of that task.  Now I’ve never claimed to be a hard core programmer, so this revelation led me to reexamine what I thought I knew about try/catch blocks within the SSIS script task. So I created a small script that I knew would fail: the following snippet causes a divide by zero error, which should be handled in the try/catch block:

Unlike the previous script task, this one succeeded:

As shown in this trivial example the try/catch block does behave as expected; exceptions within the try{} block are properly caught and do not fail the task.  So the unexpected behavior described here appears to limited to the LockOneForWrite() method (as well as its close relative LockOneForRead(), as I discovered during further testing).

The Solution (sort of….)

Now for my specific application, I was able to overcome this problem by accessing the Dts.VariableDispenser.Contains() to verify the existence of the variable I want to modify, as shown below:

… but even though I can now move on from this problem, I’m still left with no explanation as to why I’m unable to catch this exception.  I’m curious if anyone else has encountered this problem, and if so, if there’s an explanation to why the exception thrown by this particular function cannot be caught by a try/catch block.