Handling exceptions in stored procedures

Skip to first unread message


Nov 23, 2005, 7:06:33 AM11/23/05

I'm seeing some unintuitive behaviour when trying to trap exceptions in
AS managed stored procedures, and wonder whether this is intentional
behaviour and if there is any way to get around it that I'm missing.

Take the following contrived C# stored proc as an example:

public static bool Test()
Set s = MDX.StrToSet("some old nonsense");
catch {}
return true;

The programmatic StrToSet() invocation will obviously fail, but I was
expecting the try-catch block would handle the exception and prevent it
bubbling up to the calling (query) context. Unfortunately it seems
this is not the case; the calling query fails and reports back the
exception I would expect the StrToSet to raise - i.e. the exception I
thought I had suppressed. I can only assume that exceptions raised by
ADOMDServer exceptions are stored/processed somehow internally prior to
being raised to the calling code (i.e. my stored proc), and so also
bubble up to the query?

Also, if I omit the exception handling code:

public static bool Test()
Set s = MDX.StrToSet("some old nonsense");
return true;

then the calling query executes successfully and the resulting cellset
cells themselves contain the error message. So the overall effect of
my exception handling is actually to cause the whole context query to
fail, rather than succeeding but with errors reported on a cell-by-cell
basis as in the case of no exception handling.

The upshot of this is that I can't see a way to handle exceptions in my
own managed stored procedures without Analysis Services spoiling the
fun ... any comments/suggestions?


Reply all
Reply to author
0 new messages