Try before App fail

[amir.aroesti]

Hi all,

sorry about the title. Didn't find something more accurate to define my problem.

I'm a new programmer in Revit API.

due to that, sometimes my code break and the application fails.

for example, I try to edit a parameter that didn't exist in some Element.

before, when I use to work with Dynamo, if the code fails in this situation it just jumped to the next element on the list.

I wonder if there is an option to move "continue" in the algorithm if a commend fails and to create a "log" file contain the element ID that breaks the code.

hope I was clear. 

[sragan]

Yes, there is.

Its called a Try-Catch block or Try-Catch-Finally.

Search on google for C# try catch or something similar.

[RPTHOMAS108]

As I recall in Dynamo the node went yellow (or gold) telling you the exception with then everything downstream of that going the same colour.

In short how can you rely on results downstream if code isn't executed as anticipated upstream? Also depends on your language choice. VB still supports 'on error resume next' which is largely superseded by structured exception handling.

If you read up on exception handling then you may find a form of it that suits your needs. However conceptually you would be expected to anticipate many more eventualities in an add-in than in Dynamo, a Macro or a script. A parameter existing or not should not cause an exception in your code (that is an eventuality you can anticipate).

Repeatedly catching exceptions in a loop has a significant impact on performance. The majority of the time you know what exceptions will be thrown and therefore you know why they are thrown and how to avoid that. Exceptions for each API function are listed in RevitAPI.chm. Occasionally you'll get one that isn't listed but you can't generally avoid those (or design for them), since they point to larger API issues.

[sragan]

Good point.  As Jeremy would say, exceptions should be exceptional.   

So try-catch blocks should really be saved for unexpected errors and issues.

Back to the orignal post - If you really expect to be comparing parameters that might be null, test the parameter before doing the comparison.  Since you are a beginner, I'll give a short sample.  Assume you are in a loop that is getting or setting parameters.   != means "not equal".

if (myparameter != null)

{

....code to set or get parameter value

}

else

{

.... code to do something else, or just skip this to move on to the next parameter

}

You could also test to see if the parameter type matches what you are looking for (integer, string, etc.)