How should i judge points can construct face or not

[YoungOSG]

i'm writing a plugin to read points from xml. however sometimes points cann't construct face ,the plugin
will stop working.

how can i judge points can construct face or not? or can i just skip ,when points isn't qualify?

any helps? thanks!!

[tt_su]

You could try to validate yourself to make sure the points are no all co-linear and that they are all planar. But it might be easier to just rescue the error.

<span class="syntaxdefault"><br />begin<br />&nbsp;&nbsp;entities</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_face</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">points</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">rescue&nbsp;ArgumentError<br />&nbsp;&nbsp;</span><span class="syntaxcomment">#&nbsp;This&nbsp;assumes&nbsp;this&nbsp;snippet&nbsp;is&nbsp;inside&nbsp;a&nbsp;loop&nbsp;and<br />&nbsp;&nbsp;#&nbsp;we&nbsp;will&nbsp;just&nbsp;skip&nbsp;to&nbsp;the&nbsp;next&nbsp;set&nbsp;of&nbsp;points.<br />&nbsp;&nbsp;</span><span class="syntaxdefault">next&nbsp;<br />end<br /></span>

[Dan Rathbun]

The API Dictionary currently does not usually specify what Exception subclass is raised, in what situation.

It should. It would help.

Are you stating that an ArgumentError is raised when the points are not co-planar ?

[tt_su]

@dan rathbun said:

The API Dictionary currently does not usually specify what Exception subclass is raised, in what situation.

It should. It would help.

We don't have a complete overview of this ourself to be honest. Some errors come from Ruby itself, some from us. But a single API method might call a number of other utility methods that each can raise a set of argument errors - the mutations are wast.
Though, some particular errors like this would be useful in the API description. When we get the new developer site up and running it would eventually be easier to suggest corrections and improvement. Improving it has been a long standing issue which we all would like too see.

@dan rathbun said:

Are you stating that an ArgumentError is raised when the points are not co-planar ?

Just by testing in the console: (Which is what I usually do.)

Sketchup.active_model.entities.add_face([0,0,0], [9,0,0], [9,9,0], [0,9,9]) Error: #<ArgumentError: Points are not planar> <main>:inadd_face'
<main>:in <main>' -e:1:in eval'
nil`

[Dan Rathbun]

My point remains valid. You CAN see the code. You can see what exceptions the API methods raise internally themselves and their messages for ArgumentError and TypeError exceptions.

[Dan Rathbun]

@tt_su said:

We don't have a complete overview of this ourself to be honest. Some errors come from Ruby itself, some from us. But a single API method might call a number of other utility methods that each can raise a set of argument errors - the mutations are wast.

You mean "ourselves" and "the permutations are vast."

I do not feel making excuses or clouding the issue is helpful.

Engineering has always been about keeping track of things. Whomever cannot is in the wrong line of work.

Also, those that see the API documentation as an extra are wrong. It is part of the product. I have seen people come in here, take a look at the API, and dismiss SketchUp for use by their company, because of it's unprofessional and error-riddled documentation.

[tt_su]

@dan rathbun said:

My point remains valid. You CAN see the code. You can see what exceptions the API methods raise internally themselves and their messages for ArgumentError and TypeError exceptions.

It is in fact not easy to see where all the errors are raised from. I was struggling with that the other day while I was working on an issue. There are a lot of utility methods that might raise errors and it's not easy to see all the code paths.

I didn't intent to make an excuse to not so anything, but the majority of the API was made many years ago - long before anyone on my team was around. Tracing down all of them would be a lot of work. Would have been easier had it been done since the design, but alas. Just wanted to give some insight to why things are such as they are. It doesn't mean we don't agree with you.

That the documentation is not the best is well known, and you know I've ranted for years about it. One thing we really do want is a new documentation site - a new developer site.