Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IECoreArnold : Add location names to warning messages #6051

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

johnhaddon
Copy link
Member

To avoid the needle-in-a-haystack search triggered by the previous non-specific warnings.

Most of this is all straightforward, but there are a couple of things worth noting :

  • ShapeAlgo::convertP() no longer throws if it doesn't find "P". Instead it just outputs a warning and the render continues. This is more in keeping with our general "Renderers don't throw" approach.
  • ShapeAlgo::convertRadius() gained the messageContext argument but doesn't currently use it. Since this is our chance to make the ABI break needed to improve the messaging, it seemed worth adding for potential future use.

To avoid the needle-in-a-haystack search triggered by the previous non-specific warnings.

Most of this is all straightforward, but there are a couple of things worth noting :

- `ShapeAlgo::convertP()` no longer throws if it doesn't find "P". Instead it just outputs a warning and the render continues. This is more in keeping with our general "Renderers don't throw" approach.
- `ShapeAlgo::convertRadius()` gained the `messageContext` argument but doesn't currently use it. Since this is our chance to make the ABI break needed to improve the messaging, it seemed worth adding for potential future use.
@danieldresser-ie
Copy link
Contributor

Code all looks reasonable, and the things you noted sound good to me.

I'm having a slightly hard time picturing what the final resulting messages are like after following things through multiple layers, with no tests showing what things end up looking like ... I'm mostly just wondering whether we might want to sometimes include what is being, as well as the location name where the failure happens? Or maybe that will end up being obvious in context - regardless, this definitely seems like an improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Pending Review
Development

Successfully merging this pull request may close these issues.

2 participants