Error logging and reporting in Remix - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to log an error message using Remix's built-in logger.

Remix

import { json } from '@remix-run/node';

export async function loader() {
  try {
    // some code that may fail
  } catch (error) {
    console.[1]('Error loading data:', error);
    throw json({ message: 'Failed to load data' }, { status: 500 });
  }
}

Drag options to blanks, or click blank then click option'

Awarn

Berror

Clog

Dinfo

Attempts:

3 left

💡 Hint

Common Mistakes

Using console.log instead of console.error

Using console.warn which is for warnings, not errors

Use console.error to log error messages clearly in Remix.

2fill in blank

medium

Complete the code to catch and report errors in an action function in Remix.

Remix

export async function action({ request }) {
  try {
    // process request
  } catch (error) {
    return json({ error: error.message }, [1]);
  }
}

Drag options to blanks, or click blank then click option'

A{ status: 500 }

B400

C{ status: 404 }

D500

Attempts:

3 left

💡 Hint

Common Mistakes

Returning just a number instead of an object with status

Using 400 or 404 which are client errors

Return a JSON response with a status property set to 500 to indicate a server error.

3fill in blank

hard

Fix the error in the code to properly log and rethrow an error in Remix loader.

Remix

export async function loader() {
  try {
    // some code
  } catch (error) {
    console.[1](error.message);
    throw error;
  }
}

Drag options to blanks, or click blank then click option'

Aerror

Bwarn

Clog

Dinfo

Attempts:

3 left

💡 Hint

Common Mistakes

Using console.log which is less clear for errors

Using console.warn which is for warnings

Use console.error to log error messages before rethrowing.

4fill in blank

hard

Fill both blanks to create a custom error response with status and message in Remix.

Remix

import { json } from '@remix-run/node';

export function loader() {
  const errorResponse = json({ message: 'Not Found' }, [1]);
  throw errorResponse;
}

export function ErrorBoundary({ error }) {
  return <div>Error: {error.[2]</div>;
}

Drag options to blanks, or click blank then click option'

A{ status: 404 }

Bstatus

Cmessage

D{ status: 500 }

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong status code like 500

Accessing error.status instead of error.message

Use { status: 404 } to set the HTTP status and access error.message in the error boundary.

5fill in blank

hard

Fill all three blanks to log an error, return a JSON error response, and display the error message in Remix.

Remix

import { json } from '@remix-run/node';

export async function action() {
  try {
    // some action code
  } catch (error) {
    console.[1]('Action failed:', error);
    return json({ error: error.[2] }, [3]);
  }
}

export function ErrorBoundary({ error }) {
  return <div role="alert">Error: {error.error}</div>;
}

Drag options to blanks, or click blank then click option'

Aerror

Bmessage

C{ status: 500 }

Dlog

Attempts:

3 left

💡 Hint

Common Mistakes

Using console.log instead of console.error

Returning status as a number instead of an object

Accessing error directly instead of error.message

Use console.error to log errors, access error.message for the message, and return a JSON response with { status: 500 }.

Practice

1. What is the main purpose of using an ErrorBoundary component in a Remix application?

easy

A. To handle user authentication and sessions

B. To optimize database queries for faster response

C. To catch runtime errors in UI components and display fallback UI

D. To manage CSS styles dynamically

Solution

1. Step 1: Understand ErrorBoundary role

   ErrorBoundary components catch errors that happen during rendering or lifecycle methods in React-based UI, including Remix routes.

2. Step 2: Identify the purpose in Remix

   They prevent the whole app from crashing by showing a fallback UI and logging the error for developers.

3. Final Answer:

   To catch runtime errors in UI components and display fallback UI -> Option C

4. Quick Check:

   ErrorBoundary catches UI errors = A [OK]

Hint: ErrorBoundary = catch UI errors + show fallback [OK]

Common Mistakes:

• Confusing ErrorBoundary with authentication handling
• Thinking ErrorBoundary optimizes database queries
• Assuming ErrorBoundary manages CSS styles

2. Which of the following is the correct way to log an error inside a Remix loader function?

easy

A. throw new Error('Failed to load data')

B. console.error(new Error('Failed to load data'))

C. return console.log('Failed to load data')

D. console.warn('Failed to load data')

Solution

1. Step 1: Identify logging vs throwing

   Logging an error means recording it without stopping execution; console.error() is used for this.

2. Step 2: Check each option

   console.error(new Error('Failed to load data')) logs the error properly. throw new Error('Failed to load data') throws an error (not logging). return console.log('Failed to load data') returns a log (not correct usage). console.warn('Failed to load data') warns but is less severe than error.

3. Final Answer:

   console.error(new Error('Failed to load data')) -> Option B

4. Quick Check:

   Use console.error() to log errors [OK]

Hint: Use console.error() to log errors in loaders [OK]

Common Mistakes:

• Throwing error instead of logging
• Using console.log instead of console.error
• Returning console.log instead of calling it

3. Given this Remix action function snippet, what will be logged if fetchData() throws an error?

export async function action() {
  try {
    await fetchData();
  } catch (error) {
    console.error('Action error:', error);
    throw error;
  }
}

medium

A. Logs 'Action error:' followed by the error details

B. Logs error but does not throw it

C. Logs only 'Action error:' without error details

D. No log, error is thrown silently

Solution

1. Step 1: Analyze try-catch block

   If fetchData() throws, catch block runs and logs with console.error including error details.

2. Step 2: Check throw after logging

   After logging, the error is re-thrown, so it propagates further.

3. Final Answer:

   Logs 'Action error:' followed by the error details -> Option A

4. Quick Check:

   Catch logs error details before throwing [OK]

Hint: Catch logs error with details, then re-throws [OK]

Common Mistakes:

• Assuming no log happens when error thrown
• Thinking error details are not logged
• Believing error is swallowed without throw

4. You wrote this ErrorBoundary in Remix but errors are not caught as expected:

export function ErrorBoundary() {
  return <div>Error occurred</div>;
}

What is missing to properly catch and log errors?

medium

A. Use console.log inside the return statement

B. Wrap the component in try-catch block

C. Rename the function to CatchBoundary

D. Add useRouteError() hook to access error details

Solution

1. Step 1: Understand ErrorBoundary usage in Remix

   Remix requires using useRouteError() hook inside ErrorBoundary to get error info.

2. Step 2: Identify missing error access

   Without useRouteError(), the component cannot show or log error details.

3. Final Answer:

   Add useRouteError() hook to access error details -> Option D

4. Quick Check:

   useRouteError() needed to catch error info [OK]

Hint: Use useRouteError() inside ErrorBoundary to get error [OK]

Common Mistakes:

• Trying to catch errors with try-catch in component
• Logging inside return JSX (invalid)
• Confusing ErrorBoundary with CatchBoundary

5. You want to log errors from both loaders and actions in Remix and send a user-friendly message to the client. Which approach is best?

hard

A. Use try-catch in loaders/actions to log errors and return a JSON with a friendly message

B. Throw errors directly and rely on default Remix error page

C. Log errors only in ErrorBoundary and show raw error messages to users

D. Ignore errors in loaders/actions and handle only in client-side code

Solution

1. Step 1: Understand error handling in loaders/actions

   Try-catch blocks allow logging errors immediately and controlling response to client.

2. Step 2: Provide user-friendly messages

   Returning JSON with friendly messages avoids exposing raw errors and improves UX.

3. Final Answer:

   Use try-catch in loaders/actions to log errors and return a JSON with a friendly message -> Option A

4. Quick Check:

   Log and return friendly message in try-catch [OK]

Hint: Try-catch loaders/actions to log and send friendly message [OK]

Common Mistakes:

• Throwing errors without logging
• Showing raw error details to users
• Ignoring server-side errors