Revit Exceptions are System Exceptions but the .NET run-time prefers the System namespace over Revit namespace

What’s wrong with this code? Why doesn’t it catch the exception thrown by SelectNewPrintDriver if the PDF995 is not installed?

try
{
pm.SelectNewPrintDriver(“PDF995”);
}
catch (InvalidOperationException)
{
TaskDialog.Show(“Error”, “Cannot find printer PDF995”);
return;
}

Because SelectNewPrintDriver throws Autodesk.Revit.Exceptions.InvalidOperationException, not System.InvalidOperationException. So I’d suggest that you include:

using Autodesk.Revit.Exceptions;

in your files so that the compiler will give this error and remind you to resolve the ambiguity about which exception you are trying to catch.
‘InvalidOperationException’ is an ambiguous reference between ‘System.InvalidOperationException’ and ‘Autodesk.Revit.Exceptions.InvalidOperationException’

UrlEncode for Revit Server API calls

The Revit Server SDK contains a Viewer app with the following code:

WebRequest request =
WebRequest.Create(
“http://” +
tbxServerName.Text +
supportedVersions[cbxVersion.SelectedIndex, 1] +
info
);

Better would be to precede that creation of the WebRequest with this line to properly handle any special characters that might be in the path:

info = System.Web.HttpUtility.UrlEncode(info);

Don’t get tricked by Double Precision

There are plenty of good posts like these about the accuracy of numbers in Revit.

• http://spiderinnet.typepad.com/blog/2011/07/epsilon-and-tolerance-regarding-double-value-comparison-in-revit-api.html
• http://revitoped.blogspot.com/2014/01/accuracy.html

Without repeating the content of those posts, I will provide this reminder that even if you think a number will be 1, 0, -1, etc. it may be just slightly larger or smaller. And when you are debugging you might look at the value below for pf.Normal and think the Z value is exactly 0 and the surface is pointing exactly to the side.

 

But that would be a mistake, because the actual value of the Z value is not 0, as shown above.