React Error Boundaries: Core Concepts Quiz Quiz

Sharpen your frontend development skills with this quiz on Error Boundaries in React, designed to help you understand error handling, lifecycle methods, and best practices for building resilient user interfaces using error boundaries.

1. Error Boundaries Definition

   Which of the following best describes an error boundary in React?

   1. A component that catches JavaScript errors in its child component tree during rendering and shows a fallback UI.
   2. A method used to restrict user access based on authentication.
   3. A special CSS class to display boundaries during debugging.
   4. A function to track API errors in network requests.

   Explanation: An error boundary is a React component that catches JavaScript errors anywhere in its child component tree, logs them, and displays a fallback UI instead of crashing the entire app. It does not deal with authentication, so the answer about user access is incorrect. A CSS class doesn't catch errors or show fallbacks. Tracking API errors in network requests is not the primary role of error boundaries.

2. Lifecycle Methods for Error Boundaries

   Which React lifecycle method must a class component implement to act as an error boundary?

   1. componentDidCatch
   2. componentDidUpdate
   3. shouldComponentUpdate
   4. getDerivedStateFromProps

   Explanation: The componentDidCatch lifecycle method is required for a class component to function as an error boundary. It allows the component to catch errors from child components. componentDidUpdate and getDerivedStateFromProps do not handle errors. shouldComponentUpdate controls rendering behavior, not error handling.

3. Error Boundaries and Function Components

   Can you implement an error boundary using a function component in React?

   1. No, only class components can be error boundaries.
   2. Yes, function components can directly catch errors.
   3. Yes, using the useEffect hook is enough.
   4. No, but you can use try-catch in the function body.

   Explanation: As of now, error boundaries can only be implemented with class components because only they support lifecycle methods like componentDidCatch. Function components cannot directly be used as error boundaries, and the useEffect hook or try-catch in function bodies does not achieve the same result.

4. What Errors Are Caught

   Which types of errors can error boundaries catch in React?

   1. Errors during rendering, lifecycle methods, and constructors of child components
   2. Network request failures
   3. Syntax errors at compile time
   4. Errors inside event handlers

   Explanation: Error boundaries catch errors that happen during rendering, in lifecycle methods, and constructors of child components. They do not handle network request issues, compilation errors, or errors in event handlers. Event handler errors are not caught because they occur outside of rendering or lifecycle methods.

5. Fallback UI Usage

   When an error boundary catches an error, what is typically rendered?

   1. A fallback UI specified by the developer
   2. An alert popup with the error message
   3. The broken component stays on the screen
   4. The entire page automatically reloads

   Explanation: Error boundaries display a fallback UI component defined by the developer to inform users of the error gracefully. They do not show alert popups by default, nor do they reload the whole page. The broken component should not continue to display once an error is caught.

6. Placement Best Practices

   Where should you place error boundaries in a React application for optimal user experience?

   1. Around specific components that may fail, such as data-fetchers or widgets
   2. Only at the root of the entire app
   3. Directly inside every single component
   4. Around the CSS or style tags

   Explanation: It is recommended to wrap potentially unstable components with error boundaries, so if a part fails, the rest of the UI stays intact. Placing an error boundary only at the app root may hide where the error came from. Wrapping every component is unnecessary, and wrapping style tags serves no purpose.

7. Event Handler Errors

   How should you handle errors that occur inside event handler functions, such as onClick, in React?

   1. Use regular try-catch statements inside the event handler
   2. Error boundaries will automatically catch these errors
   3. Add an extra error boundary around the event handler
   4. They cannot be handled at all

   Explanation: Errors thrown in event handlers are not caught by error boundaries. Instead, developers need to use try-catch within the event handler function to manage such errors. Error boundaries and extra wrappers do not catch these runtime errors. The statement that errors cannot be handled at all is incorrect as try-catch provides a way.

8. Resetting Error Boundaries

   What action commonly resets the error state of an error boundary component to allow re-rendering?

   1. Changing the key prop on the error boundary
   2. Reloading the browser window
   3. Calling setError directly on children
   4. Importing error boundary again

   Explanation: Changing the key prop on the error boundary causes it to remount, clearing any previously captured errors and allowing re-rendering. Reloading the browser refreshes the entire app, which is unnecessary. setError is not a standard method, and importing again has no effect.

9. Error Boundary Scope

   If an error occurs in a child component, what happens to sibling components not wrapped by the same error boundary?

   1. They are unaffected and continue to render normally.
   2. They are hidden along with the error boundary.
   3. They throw errors as well.
   4. They are automatically wrapped in a fallback UI.

   Explanation: Only the descendants of an error boundary are affected when an error is caught; sibling components outside the error boundary are not impacted and continue rendering. Siblings are not hidden or wrapped in the fallback UI. Errors do not cascade to siblings unless wrapped together.

10. Class Component Signature

    Which two methods are required to create a working error boundary class component in React?

    1. render and componentDidCatch
    2. componentDidMount and setState
    3. render and shouldComponentUpdate
    4. constructor and componentWillReceiveProps

    Explanation: A valid error boundary must implement a render method to display content and componentDidCatch to catch errors. The other options list methods not related to error boundaries. componentDidMount initializes logic but does not catch errors. constructor and other lifecycle methods are optional, not required.

11. getDerivedStateFromError Purpose

    What is the purpose of the getDerivedStateFromError static method in error boundaries?

    1. To update state when an error is thrown before rendering fallback UI
    2. To fetch data when a component mounts
    3. To handle API errors
    4. To schedule updates after state changes

    Explanation: getDerivedStateFromError allows updating the state when an error is thrown, which then triggers rendering the fallback UI. It is not used for data fetching, API error handling, or scheduling state updates after changes. The other options do not describe its error handling purpose.

12. Supported React Versions

    From which major version of React are error boundaries officially supported?

    1. 16.0
    2. 13.0
    3. 15.5
    4. 17.2

    Explanation: Error boundaries were introduced in React version 16.0, making it the first version with official support. Versions 13.0 and 15.5 did not have this feature, and 17.2 is a later version with error boundaries already established.

13. Logging Errors

    What is a typical use for the error and info arguments received by componentDidCatch in an error boundary?

    1. Logging error details to an external error tracking service
    2. Generating CSS styles for fallback UI
    3. Updating unrelated state values in the app
    4. Directly fixing bugs in child components automatically

    Explanation: componentDidCatch often logs errors and additional info to an external service for diagnosis. It does not generate CSS, update unrelated state, or automatically fix bugs. The main purpose is to capture and report errors, not resolve them directly.

14. Uncaught Errors

    What happens if an error is not caught by any error boundary in a React tree?

    1. The entire component tree below the error is unmounted.
    2. Only the failing component stops rendering, but the rest of the UI is fine.
    3. Nothing happens; the error is ignored safely.
    4. The error is retried until fixed.

    Explanation: If an error isn't caught by an error boundary, React unmounts the entire component tree below the component that threw the error, possibly causing a blank screen. Errors are not ignored, retried, or self-limited to the failing component without error boundaries.

15. Fallback UI Customization

    How can you display different fallback UIs for different sections in a React application with error boundaries?

    1. Wrap each section with its own error boundary specifying a custom fallback UI
    2. Apply global CSS to change fallback appearance for all errors
    3. Place a fallback UI inside the index.html file
    4. Use a single error boundary for the entire application

    Explanation: Wrapping each section in its own error boundary allows customized fallback UIs for different areas. Global CSS doesn't control error boundary content, and putting a fallback in index.html is not reactive to app errors. A single boundary for the whole app limits customization.

16. What Error Boundaries Cannot Catch

    Select a scenario where React error boundaries are unable to catch an error.

    1. Error thrown in an onClick event handler
    2. Error thrown during a child component's rendering
    3. Error thrown in a child component's constructor
    4. Error thrown in a child component's lifecycle method

    Explanation: Error boundaries do not catch errors thrown in event handlers like onClick, which need separate handling. They do catch errors thrown during rendering, in constructors, and in lifecycle methods of child components, making those choices incorrect for this scenario.