Questions
1 of 4
What is the difference between errors.Is and errors.As?
Difficulty: 5/10
error handling, type assertions, standard library
errors.Is checks if any error in the chain matches a specific sentinel error by value. errors.As checks if any error in the chain can be assigned to a specific type and extracts it.
errors.Is and errors.As examples
When to use each
- 1
errors.Is: comparing against sentinel errors like sql.ErrNoRows, io.EOF, context.DeadlineExceeded
- 2
errors.As: extracting typed errors to access additional fields (HTTP status code, DB error code)
- 3
Both unwrap the error chain — wrapping with %w is essential for them to work
- 4
errors.Is uses == comparison by default; implement Is(error) bool on custom types for custom matching
- 5
errors.As uses type assignability — it finds the first error in chain assignable to the target type
Scenario Questions
0-2 years experience
- 1You have a function that returns an error wrapped with fmt.Errorf("%w", err). How would you check if the returned error is net.ErrClosed using errors.Is versus errors.As?
- 2A library returns a custom error type MyError that implements the error interface. Walk me through how you'd extract that type with errors.As and why errors.Is wouldn't be sufficient.
2-5 years experience
- 1After a recent deployment, some callers started seeing unexpected behavior when they used errors.Is to detect a timeout error that is now wrapped inside a custom RetryError. How would you debug the issue and decide whether to switch to errors.As?
- 2In a feature that retries on temporary network failures, you need to differentiate between timeout errors and custom retryable errors that embed other errors. Explain how you'd structure the checks using errors.Is and errors.As, and what trade‑offs you consider.
5-8 years experience
- 1Our microservice aggregates errors from multiple downstream services and wraps them before returning to the client. At scale we need to log the concrete error types for alerting while also supporting generic error matching. Design an error‑handling strategy that leverages errors.Is and errors.As, and discuss performance and maintainability implications.
- 2We are refactoring a legacy codebase that uses string comparison of error messages. Describe how you would migrate to errors.Is / errors.As across the codebase, handling cases where errors are wrapped multiple times and where custom error types lack Unwrap.
8+ years experience
- 1Across several teams we have a shared error taxonomy that includes sentinel errors, wrapped errors, and typed errors. How would you define a cross‑service contract that allows each team to reliably detect specific error conditions using errors.Is and errors.As, while keeping the contract stable for future extensions?
- 2Our organization is moving from Go 1.12 to Go 1.20, and we want to introduce a centralized error handling library that abstracts errors.Is and errors.As. What architectural considerations would you evaluate (e.g., version compatibility, observability, backward compatibility), and how would you design the library to avoid misuse?
Follow-up Questions
- What happens if the error you pass to errors.Is doesn't implement Unwrap?
- Can you show a minimal example where errors.As is required because the concrete type carries extra data?
- How would you test that your error‑checking logic works with multiple layers of wrapping?