topic Re: Error handling for unclassified elements in Documentation

Error handling for unclassified elements

Bruce — Wed, 08 Feb 2023 22:41:54 GMT

Is there a way to test for an unclassified element in a Property Expression, and return an empty string instead of a #hashtag? A similar Excel formula would be "=ISNA()"

E.g. we are concatenating our wall label from multiple properties to have one label that has (for example), the wall type, the fire rating, the acoustic rating etc. One of these is "Wall Core", which is only available for the "Solid Wall" classification. However, we also have labels attached to walls that are classified as "Partition Wall", which result in a #hashtag error.

As far as I can tell, if the Property isn't available, then the expression doesn't even run.

Re: Error handling for unclassified elements

runxel — Thu, 09 Feb 2023 14:48:27 GMT

The solution is in your last sentence already.

You don't need to explicitly test for some classification. If the expression can't be evaluated (e.g. because one element does not have this property), it will be skipped. But please bear in mind: you can add as many expressions as wanted. AC will take the first applicable one. In this example if some element does not have "some property", it will just get a static "foo" applied. Cool, huh?

Re: Error handling for unclassified elements

Bruce — Thu, 09 Feb 2023 21:17:22 GMT

Thanks runxel,

Although this would work for one, maybe two combined properties, we have five or six, with either an "N/A", or the value. The end result would look something like:

WT1 | CRC1 | 30/30/30 | RW45 | R3.2

Where if any of those values were "N/A", they wouldn't appear in the final concatenated property. It's a long CONCAT statement, with heaps of nested IF statements, e.g. IF(CORE TYPE = "N/A", "", (CONCAT CORE TYPE, "|")).

We could get around it with a proxy property to test, but this introduces new properties, and all properties create processing overhead which has significant impact on larger projects.

Re: Error handling for unclassified elements

runxel — Thu, 09 Feb 2023 22:40:32 GMT

Okay I can see that this produces some overhead for larger concatenated properties.

I have the same thing going on for fire safety properties. But since I might need the parts for themself anyway I have them seperate. I really don't care, I was not able to see any performance drops so far with having a few more properties.

So a workaround for you would be to split your one big property into its constituting parts and having a "fallback". Could be e.g. a special character, which you then use to test for (instead of your "N/A").

Re: Error handling for unclassified elements

Bruce — Fri, 10 Feb 2023 00:25:52 GMT

Yes, we do have our properties split out, as you've described. "N/A" is our 'special' character...but if the property isn't in the classification, it can't produce even the special character to test for. This is the problem we're running into.

This would be solved if we could test for a null value. e.g. ISNULL.

Re: Error handling for unclassified elements

Barry Kelly — Fri, 10 Feb 2023 00:30:59 GMT

Have you tried empty quotes "".

This is a null string.

Barry.

Re: Error handling for unclassified elements

Bruce — Fri, 10 Feb 2023 01:26:18 GMT

Good idea Barry. Unfortunately, no, that didn't work.

Re: Error handling for unclassified elements

runxel — Fri, 10 Feb 2023 09:43:27 GMT

Yeah you're right Bruce, sorry.

My suggestion doesn't help when the whole property is not available.

The other workaround still works. But I see it is cumbersome to generate all versions, especially when every one of the parts could be missing. This would like 5! (=120) versions? 😅

So yeah, valid wish.