stop a feature on a condition

EvanReese

What's the best way to stop a feature from processing and add a warning report? I assumed erroneously that just adding reportFeatureWarning would prevent the rest of the feature from processing and just display the warning, but it seems to fail because of downstream things instead. I could put everything after in a giant if/then, but something tells me that's not how the pros do it. Suggestions?

If it's relevant, the failure mode is an array index out of bounds.

MBartlett21

@Evan_Reese
You can wrap the top-level function in a try-catch block and then use `reportFeatureWarning` on the error at the end.

To do the error, you can the use `throw "This is the error that Jack threw"`

EDIT: Note: if the error propagates all the way past your function, and is not a regenError the user only gets a form error: Error regenerating.

Alex_Kempen

Information on error handling can be found in the error handling section of the FS documentation. The short of it is that throw regenError is used to hit the brakes, since it stops your feature from regenerating, resulting in your feature producing nothing. You can also attach custom error messages to regenErrors and tag incorrect parameters and queries so they highlight in red, which is useful for accurately reporting what went wrong.

reportFeatureWarning is less severe than regenError, causing your feature to turn red but still regenerate (i.e. create and/or modify your part studio). An example usage is in my belt FeatureScript, where I use reportFeatureWarning to warn the user if the user's selected belt run doesn't match the distance between their selections. In this case, I want the user to know something is wrong, but the belt FS should also still create the belt and pulleys, so reportFeatureWarning works fine for that situation.

Try and catch statements can be used with all types of warnings to prevent unhelpful errors from appearing; here's a common usage pattern:

try 
{
  opExtrude(context, id, extrudeDef);
}
catch
{
  throw regenError("Error message goes here."); // can optionally append parameters and queries to tag in red
}

Note that you could also avoid the use of the try/catch statement by preprocessing the extrudeDefinition using if statements, which could allow for even more accurate error warnings, depending on what you're doing.

if (evaluateQuery(context, extrudeDef.entities) == [])
  throw regenError("Select entities to extrude.", ["entities"]); // where definition.entities is a parameter<br>

You can also use the verifyNonemptyQuery method to get the same effect.

Lastly, reportFeatureInfo can be used to simply display a message popup, without affecting the model state in any way. This is great for things like success messages.

Hopefully, that makes some sense and helps answer your questions.

MBartlett21

@Evan_Reese
You can wrap the top-level function in a try-catch block and then use `reportFeatureWarning` on the error at the end.

To do the error, you can the use `throw "This is the error that Jack threw"`

EDIT: Note: if the error propagates all the way past your function, and is not a regenError the user only gets a form error: Error regenerating.

Alex_Kempen

Information on error handling can be found in the error handling section of the FS documentation. The short of it is that throw regenError is used to hit the brakes, since it stops your feature from regenerating, resulting in your feature producing nothing. You can also attach custom error messages to regenErrors and tag incorrect parameters and queries so they highlight in red, which is useful for accurately reporting what went wrong.

reportFeatureWarning is less severe than regenError, causing your feature to turn red but still regenerate (i.e. create and/or modify your part studio). An example usage is in my belt FeatureScript, where I use reportFeatureWarning to warn the user if the user's selected belt run doesn't match the distance between their selections. In this case, I want the user to know something is wrong, but the belt FS should also still create the belt and pulleys, so reportFeatureWarning works fine for that situation.

Try and catch statements can be used with all types of warnings to prevent unhelpful errors from appearing; here's a common usage pattern:

try 
{
  opExtrude(context, id, extrudeDef);
}
catch
{
  throw regenError("Error message goes here."); // can optionally append parameters and queries to tag in red
}

Note that you could also avoid the use of the try/catch statement by preprocessing the extrudeDefinition using if statements, which could allow for even more accurate error warnings, depending on what you're doing.

if (evaluateQuery(context, extrudeDef.entities) == [])
  throw regenError("Select entities to extrude.", ["entities"]); // where definition.entities is a parameter<br>

You can also use the verifyNonemptyQuery method to get the same effect.

Lastly, reportFeatureInfo can be used to simply display a message popup, without affecting the model state in any way. This is great for things like success messages.

Hopefully, that makes some sense and helps answer your questions.

EvanReese

Thank you both for clarifying the differences here. I'd really like the warning message to appear at the top of the screen, not just when mousing over the failed feature, so I'll stick with the warning and some other logic to keep it from regenerating.

Alex_Kempen

Hmm that might be the best course of action in this situation. I thought regenErrors could also give messages, but I guess not. I'm not sure if you'll be able to combine a message pop-up with the error then, since I think the regenError will overwrite any message you have displayed, even if you do something like ErrorStringEnum.NO_ERROR. If you really want the message pop-up, then your best bet might be to still allow your feature to regenerate, either by skipping remaining code sections, allowing them to run uselessly, or by using something like a return statement in the feature body to end the feature early.