Skip to content

Add error handling for mid-parental-height functions#78

Open
FibrinLab wants to merge 1 commit intorcpch:livefrom
FibrinLab:add-mid-parental-height-validation
Open

Add error handling for mid-parental-height functions#78
FibrinLab wants to merge 1 commit intorcpch:livefrom
FibrinLab:add-mid-parental-height-validation

Conversation

@FibrinLab
Copy link

Fixes issue: mid-parental-height accepts impossible values #53

  • Add MAXIMUM_PARENTAL_HEIGHT_CM constant (260 cm) to validation_constants.py
  • Add comprehensive input validation to mid_parental_height() function
  • Add input validation to mid_parental_height_z() function
  • Add 7 new test functions covering all validation scenarios

- Add MAXIMUM_PARENTAL_HEIGHT_CM constant (260 cm) to validation_constants.py
- Add comprehensive input validation to mid_parental_height() function:
  * Validate sex parameter (must be 'male' or 'female')
  * Validate maternal_height (None, type, range 50-260 cm)
  * Validate paternal_height (None, type, range 50-260 cm)
- Add comprehensive input validation to mid_parental_height_z() function:
  * Validate reference parameter
  * Validate maternal_height (None, type, range 50-260 cm)
  * Validate paternal_height (None, type, range 50-260 cm)
- Add 7 new test functions covering all validation scenarios
- All tests pass (22,767 total tests)

Fixes issue: mid-parental-height accepts impossible values
@mbarton mbarton self-assigned this Jan 26, 2026
@mbarton
Copy link
Member

mbarton commented Jan 26, 2026

Thanks for the contribution @FibrinLab! It looks fine from a code point of view however we will need to run this past the statisticians who advise us before merging. Hopefully won't take too long :)

@eatyourpeas
Copy link
Member

Good job @FibrinLab thank you. The reason there is no error handling in the python package is because we put it in the server - see here: https://github.com/rcpch/digital-growth-charts-server/blob/live/routers/utilities.py
Actually though you make a really good point that we should have this in the package too for peope who consume it without the API.

I can see you have used the Guiness Book of Records values to set min and max. We did deprecate this in favour of using SDS cut offs - might you be happy to review the approach taken above in the server and then replicate here? That way I can remove the code in the server and just trap the errors raised in the package and return those to the user?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants