In this session - we’ll explore how GraphQL Clients can provide a road for developers to make full use of Semantic Nullability! GraphQL Spec defines that field errors should result in a null value. This makes null values ambiguous - either null due to error - or null due to nullability. Semantic Nullability allows you to define nullability explicitly - see https://github.com/graphql/graphql-wg/discussions/1410 Therefore, GraphQL Clients need to be able to handle errors differently - giving engineers more confidence in how field states are handled. In this session, we'll cover: 1. Why explicitly handling errors can enable us to move to a new normal where all errors are surfaced explicitly (throw-by-default on error) 2. How using @catch directive allows us to differentiate error nulls from true nulls in product code 3. Steps 1 and 2 will require developers to handle errors explicitly - and this opens the door to Semantic Nullability! I’ll also cover how working on the @catch directive helped push the semantic nullability conversation forward, the rollout at Meta, and what future capabilities can be unlocked. Original proposal: https://github.com/facebook/relay/issues/4416