(Part of our Revit API 2011 Series)
Forgive the bad pun of a title…
One of the new capabilities in the Revit 2011 API that I haven’t covered yet is some re-working of the way that Revit throws exceptions when you do something it doesn’t like… Whereas in the past, you would have gotten something pretty generic (in terms of the type of exception thrown), in 2011 Autodesk has introduced a variety of very specific Revit exceptions which are thrown. All of these inherit from Autodesk.Revit.Exceptions.ApplicationException:
- ApplicationException
- ArgumentException
- ArgumentNullException
- ArgumentOutOfRangeException
- ArgumentsInconsistentException
- FileArgumentNotFoundException
- InvalidPathArgumentException
- InternalException
- InvalidOperationException
- AutoJoinFailedException
- FamilyContextException
- ForbiddenForDynamicUpdateException
- InapplicableDataException
- IncorrectProductException
- InvalidLicenseException
- InvalidObjectException
- ModificationForbiddenException
- ModificationOutsideTransactionException
- ObjectAccessException
- RegenerationFailedException
- IOException
- DirectoryNotFoundException
- FileAccessException
- FileNotFoundException
- InvalidDataStreamException
- ArgumentException
So what, you say? An exception is an exception, you say? I disagree – historically it has been painful to try to figure out why something didn’t work in Revit – the exceptions and error messages were not always helpful. And if you wanted to trap specific exceptions, it was pretty weak.
I see this as a great investment on Autodesk’s part in making the Revit API “grow up” to a level of maturity that you can develop strong applications with it. Applications that are easier to control and to diagnose when something goes wrong.
And speaking of diagnosis, there’s one other hidden gem in all these exceptions: the FunctionId. A property on these exceptions which gives you:
- The Revit source code file
- The Revit source code function
- The Revit source code line number
where this particular exception occurred. This strikes me as a great help when I’m sending something in to Autodesk Developer Network… Telling them EXACTLY where in their code something is going bad (and to help me figure out why).
All in all, I appreciate that they took some time to implement this in 2011.
Obscure Developer TechNote:
One thing that I had not been expecting… If you use the “Debug + Exceptions + Thrown Exceptions” in Visual Studio… When a Revit Exception is first thrown, it shows up as an “SEHException” which I believe means an unmanaged C++ exception that is bubbling up. That said, when it actually arrives – it is one of the new types shown above. So you actually have to let it bubble all the way up before you get the benefit of the knowledge of what it is.
No comments:
Post a Comment