7a:T66b,// The exception model in action public class UserService { private UserRepository repository; private EmailService emailService; public User createUser(String email, String password) { // Each of these methods might throw exceptions validateEmail(email); // throws InvalidEmailException validatePassword(password); // throws WeakPasswordException if (repository.existsByEmail(email)) { throw new EmailAlreadyExistsException(email); } User user = new User(email, hashPassword(password)); repository.save(user); // throws DatabaseException emailService.sendWelcome(user); // throws EmailServiceException return user; } } // Caller must handle or propagate exceptions public class UserController { private UserService userService; public Response handleRegistration(Request request) { try { User user = userService.createUser( request.getEmail(), request.getPassword() ); return Response.created(user); } catch (InvalidEmailException e) { return Response.badRequest("Invalid email format"); } catch (WeakPasswordException e) { return Response.badRequest("Password too weak"); } catch (EmailAlreadyExistsException e) { return Response.conflict("Email already registered"); } catch (DatabaseException e) { log.error("Database error", e); return Response.serverError("Please try again later"); } } }7b:T643,# The exception model in action class UserService: def __init__(self, repository, email_service): self.repository = repository self.email_service = email_service def create_user(self, email: str, password: str) -> User: # Each of these might raise exceptions self.validate_email(email) # raises InvalidEmailError self.validate_password(password) # raises WeakPasswordError if self.repository.exists_by_email(email): raise EmailAlreadyExistsError(email) user = User(email, self.hash_password(password)) self.repository.save(user) # raises DatabaseError self.email_service.send_welcome(user) # raises EmailServiceError return user # Caller must handle or propagate exceptions class UserController: def __init__(self, user_service): self.user_service = user_service def handle_registration(self, request): try: user = self.user_service.create_user( request.email, request.password ) return Response.created(user) except InvalidEmailError: return Response.bad_request("Invalid email format") except WeakPasswordError: return Response.bad_request("Password too weak") except EmailAlreadyExistsError: return Response.conflict("Email already registered") except DatabaseError as e: logging.error(f"Database error: {e}") return Response.server_error("Please try again later")7c:T8e9,// The error state model in Rust use thiserror::Error; #[derive(Error, Debug)] pub enum CreateUserError { #[error("Invalid email format: {0}")] InvalidEmail(String), #[error("Password too weak: {0}")] WeakPassword(String), #[error("Email already exists: {0}")] EmailExists(String), #[error("Database error: {0}")] Database(#[from] DatabaseError), #[error("Email service error: {0}")] EmailService(#[from] EmailServiceError), } impl UserService { pub fn create_user( &self, email: &str, password: &str ) -> Result { // Each operation returns a Result that must be handled self.validate_email(email)?; // ? propagates errors self.validate_password(password)?; if self.repository.exists_by_email(email)? { return Err(CreateUserError::EmailExists(email.into())); } let user = User::new(email, self.hash_password(password)); self.repository.save(&user)?; self.email_service.send_welcome(&user)?; Ok(user) } } // Caller must handle the Result impl UserController { pub fn handle_registration(&self, request: Request) -> Response { match self.user_service.create_user(&request.email, &request.password) { Ok(user) => Response::created(user), Err(CreateUserError::InvalidEmail(msg)) => { Response::bad_request(&format!("Invalid email: {}", msg)) } Err(CreateUserError::WeakPassword(msg)) => { Response::bad_request(&format!("Weak password: {}", msg)) } Err(CreateUserError::EmailExists(_)) => { Response::conflict("Email already registered") } Err(CreateUserError::Database(e)) => { log::error!("Database error: {:?}", e); Response::server_error("Please try again later") } Err(CreateUserError::EmailService(e)) => { log::warn!("Email service error: {:?}", e); // User created but email failed - might still return success Response::created_with_warning("Welcome email failed") } } } }7d:Tbcc,// Error state model in TypeScript using discriminated unions type CreateUserError = | { type: 'INVALID_EMAIL'; message: string } | { type: 'WEAK_PASSWORD'; message: string } | { type: 'EMAIL_EXISTS'; email: string } | { type: 'DATABASE_ERROR'; cause: Error } | { type: 'EMAIL_SERVICE_ERROR'; cause: Error }; type Result = | { success: true; value: T } | { success: false; error: E }; class UserService { async createUser( email: string, password: string ): Promise> { // Validate email const emailValidation = this.validateEmail(email); if (!emailValidation.success) { return { success: false, error: emailValidation.error }; } // Validate password const passwordValidation = this.validatePassword(password); if (!passwordValidation.success) { return { success: false, error: passwordValidation.error }; } // Check existence const existsResult = await this.repository.existsByEmail(email); if (!existsResult.success) { return { success: false, error: existsResult.error }; } if (existsResult.value) { return { success: false, error: { type: 'EMAIL_EXISTS', email } }; } // Create and save const user = new User(email, this.hashPassword(password)); const saveResult = await this.repository.save(user); if (!saveResult.success) { return { success: false, error: saveResult.error }; } // Send welcome email (non-blocking) const emailResult = await this.emailService.sendWelcome(user); if (!emailResult.success) { console.warn('Welcome email failed:', emailResult.error); // Continue anyway - user was created } return { success: true, value: user }; } } // Caller handles the result explicitly class UserController { async handleRegistration(request: Request): Promise { const result = await this.userService.createUser( request.email, request.password ); if (result.success) { return Response.created(result.value); } switch (result.error.type) { case 'INVALID_EMAIL': case 'WEAK_PASSWORD': return Response.badRequest(result.error.message); case 'EMAIL_EXISTS': return Response.conflict('Email already registered'); case 'DATABASE_ERROR': console.error('Database error:', result.error.cause); return Response.serverError('Please try again later'); case 'EMAIL_SERVICE_ERROR': // Should not reach here based on implementation return Response.serverError('Unexpected error'); } } }7e:T58a,impl TransferService { pub fn transfer_money( &self, from: &mut Account, to: &mut Account, amount: Money, ) -> Result { // With Result types, every fallible operation is visible let _from_lock = self.lock_manager.acquire(from)?; let _to_lock = self.lock_manager.acquire(to)?; // Explicit: this can fail with InsufficientFunds from.debit(amount)?; // If credit fails, we need to compensate if let Err(e) = to.credit(amount) { // Rollback the debit from.credit(amount).expect("Rollback must succeed"); return Err(e.into()); } // Audit log failure is logged but doesn't fail the transfer if let Err(e) = self.audit_log.record(from, to, amount) { log::error!("Audit log failed: {:?}", e); // Continue - transfer succeeded } // Notification failure is just a warning if let Err(e) = self.notification_service.notify( from.get_owner(), "Transfer complete" ) { log::warn!("Notification failed: {:?}", e); } Ok(TransferReceipt::new(from, to, amount)) } } // Reading this code, every possible failure point is visible. // The handling strategy for each is explicit and reviewable.7f:T603,#[cfg(test)] mod tests { use super::*; #[test] fn create_user_with_invalid_email_returns_validation_error() { let service = UserService::new(mock_repository(), mock_email()); let result = service.create_user("not-an-email", "ValidPass123!"); // Error is a value we can assert on assert!(result.is_err()); match result.unwrap_err() { CreateUserError::InvalidEmail(msg) => { assert!(msg.contains("@")); } other => panic!("Expected InvalidEmail, got {:?}", other), } } #[test] fn create_user_with_existing_email_returns_conflict() { let mut mock_repo = mock_repository(); mock_repo.expect_exists_by_email() .returning(|_| Ok(true)); // Email exists let service = UserService::new(mock_repo, mock_email()); let result = service.create_user("taken@example.com", "ValidPass123!"); assert!(matches!(result, Err(CreateUserError::EmailExists(_)))); } #[test] fn create_user_database_failure_is_propagated() { let mut mock_repo = mock_repository(); mock_repo.expect_save() .returning(|_| Err(DatabaseError::ConnectionLost)); let service = UserService::new(mock_repo, mock_email()); let result = service.create_user("new@example.com", "ValidPass123!"); assert!(matches!(result, Err(CreateUserError::Database(_)))); } }80:T807,describe('UserService', () => { describe('createUser', () => { it('returns validation error for invalid email', async () => { const service = new UserService(mockRepository(), mockEmail()); const result = await service.createUser( 'not-an-email', 'ValidPass123!' ); // Error is a value we can assert on expect(result.success).toBe(false); if (!result.success) { expect(result.error.type).toBe('INVALID_EMAIL'); expect(result.error.message).toContain('@'); } }); it('returns conflict error for existing email', async () => { const mockRepo = mockRepository(); mockRepo.existsByEmail.mockResolvedValue({ success: true, value: true }); const service = new UserService(mockRepo, mockEmail()); const result = await service.createUser( 'taken@example.com', 'ValidPass123!' ); expect(result.success).toBe(false); if (!result.success) { expect(result.error.type).toBe('EMAIL_EXISTS'); } }); it('propagates database errors', async () => { const mockRepo = mockRepository(); mockRepo.save.mockResolvedValue({ success: false, error: { type: 'DATABASE_ERROR', cause: new Error('Connection lost') } }); const service = new UserService(mockRepo, mockEmail()); const result = await service.createUser( 'new@example.com', 'ValidPass123!' ); expect(result.success).toBe(false); if (!result.success) { expect(result.error.type).toBe('DATABASE_ERROR'); } }); }); });72:{"json":{"id":"seed_987f218122010eef91aca4fa7cb70a8c","slug":"error-states-and-result-types","category":"System Design (LLD)","topic":"Error States and Result Types","title":"Error States and Result Types","description":"Master alternative error handling strategies beyond exceptions. Learn to design with Result, Either, and Option types to create explicit, composable, and type-safe error handling that makes failure conditions impossible to ignore.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_753697bd3603c0d44d6b670d4c3d68aa","title":"Error States vs Exceptions","order":0,"content":[{"id":"opening-hook","title":"Two Philosophies of Failure","content":[{"data":{"content":"Every software system encounters failures. Network connections drop, files don't exist, users provide invalid input, and resources become exhausted. How we represent and handle these failures is one of the most consequential design decisions in any codebase.\n\n**There are fundamentally two approaches:**\n\n1. **Exceptions** — Failures are signaled by throwing/raising an exception, which disrupts normal control flow and unwinds the call stack until a handler catches it.\n\n2. **Error States** — Failures are represented as explicit values that functions return. The caller must inspect the result to determine if the operation succeeded.\n\nNeither approach is universally superior. Each embodies different philosophies about how software should handle failure, and each excels in different contexts. Understanding both deeply is essential for designing robust systems."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the fundamental tradeoffs between exceptions and error states, recognize when each approach is appropriate, and appreciate why modern languages increasingly offer both paradigms. You'll develop intuition for choosing the right error representation based on failure semantics and system requirements.","variant":"info"},"type":"callout"}]},{"id":"exception-model","title":"The Exception Model","content":[{"data":{"content":"Exceptions emerged in the 1960s and became mainstream through languages like C++, Java, and Python. The exception model treats failures as **exceptional events** that disrupt normal program flow.\n\n**How exceptions work:**\n\n1. When a failure occurs, the function *throws* an exception object\n2. Normal execution immediately stops\n3. The runtime searches up the call stack for a matching *catch* block\n4. If found, execution resumes in the catch block\n5. If not found, the program terminates (usually with a stack trace)\n\nThis mechanism provides a form of **non-local control flow** — execution can jump from deep in the call stack directly to a handler many levels up."},"type":"text"},{"data":{"fileName":"exception_model_example","languages":[{"code":"$7a","label":"Java","value":"java"},{"code":"$7b","label":"Python","value":"python"}]},"type":"code"},{"data":{"items":["**Clean happy path** — The normal case reads clearly without interleaved error handling; success flow is uninterrupted and highly readable.","**Automatic propagation** — Exceptions propagate up the call stack automatically; intermediate functions don't need to handle errors they can't meaningfully address.","**Rich diagnostic information** — Exception objects carry stack traces, messages, and can form chains, providing excellent debugging context.","**Guaranteed cleanup** — Finally blocks (or destructors) execute regardless of how a block exits, ensuring resource cleanup.","**Handles truly exceptional cases well** — For programming errors or irrecoverable conditions, exceptions provide appropriate severity signaling."],"title":{"icon":"CheckCircle","text":"Strengths of the Exception Model","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":1},{"id":"error-state-model","title":"The Error State Model","content":[{"data":{"content":"The error state model treats failures as **expected possibilities** that should be represented explicitly in a function's return type. Rather than disrupting control flow, operations return values that might represent either success or failure.\n\n**How error states work:**\n\n1. Functions return a composite type that can represent success or failure\n2. The caller **must** inspect this return value to access the result\n3. Error handling is **local** — each call site deals with its immediate result\n4. The type system enforces that failure cases cannot be accidentally ignored\n5. Composition is achieved through explicit transformation functions\n\nThis approach originated in functional programming languages (ML, Haskell) and has spread to imperative languages through types like Rust's `Result`, Kotlin's `Result`, and Swift's `Result`."},"type":"text"},{"data":{"fileName":"error_state_model_example","languages":[{"code":"$7c","label":"Rust","value":"rust"},{"code":"$7d","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"items":["**Explicit error handling** — Failure cases are visible in the type system; the compiler ensures you handle them, eliminating forgotten error paths.","**Local reasoning** — Each function call site handles its errors immediately; you can understand error handling without tracing call stacks.","**No hidden control flow** — Execution follows visible paths; there are no secret jumps or stack unwinding that might bypass important code.","**Composable operations** — Result types support map, flatMap/andThen, and other combinators for elegant error transformation chains.","**Precise error types** — The type system documents exactly which errors can occur, serving as self-documenting, verifiable contracts."],"title":{"icon":"CheckCircle","text":"Strengths of the Error State Model","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":2},{"id":"comparing-models","title":"Comparing the Two Models","content":[{"data":{"content":"The choice between exceptions and error states isn't merely syntactic—it reflects fundamentally different views about what failures mean and how they should be handled. Let's examine the key differences:"},"type":"text"},{"data":{"rows":[["**Visibility**","Implicit — not visible in function signatures (except Java's checked exceptions)","Explicit — failure possibility encoded in the return type"],["**Control Flow**","Non-local — can jump multiple stack frames","Local — errors handled at each call site"],["**Compiler Enforcement**","Generally none (except checked exceptions)","Full enforcement — must handle before accessing value"],["**Happy Path Clarity**","Very clean — no error handling code inline","More verbose — error handling interleaved (though mitigated by combinators)"],["**Composition**","Try-catch nesting can become awkward","Natural with map/flatMap/andThen operators"],["**Performance**","Zero-cost happy path, expensive on throw","Slight overhead always (result wrapper), no throw cost"],["**Concurrent Code**","Exceptions don't cross thread boundaries easily","Error states are just values — cross boundaries naturally"],["**Recoverable vs Fatal**","Often conflated — same mechanism for both","Usually separate — Result for recoverable, panic for fatal"]],"caption":"Exceptions vs Error States: A Deep Comparison","headers":["Dimension","Exceptions","Error States (Result Types)"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"The Performance Consideration","content":"In most applications, exception throwing is rare enough that performance doesn't matter. However, in hot paths where failures are common (parsing user input, network operations), the cost of throwing can become significant. Error states have consistent, predictable performance regardless of success or failure.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"semantic-distinction","title":"The Semantic Distinction: Expected vs Exceptional","content":[{"data":{"content":"The most important distinction between these models is **semantic** — what kind of failure are we representing?\n\n**Exceptional failures** are situations that:\n- Are unexpected in normal operation\n- Represent programming errors or environmental failures\n- Often cannot be meaningfully recovered from\n- Require immediate attention\n\n**Expected failures** are situations that:\n- Are anticipated possibilities in normal operation\n- Represent valid outcomes of an operation (just not the happy path)\n- Can and should be handled gracefully\n- Are part of the function's contract\n\nMapping these semantics to mechanisms:"},"type":"text"},{"data":{"left":[{"data":{"items":["**Programming errors** — Null pointer dereference, index out of bounds, assertion failures","**Invariant violations** — System state corruption, impossible conditions reached","**Unrecoverable resource failures** — Out of memory, disk full, system call failures","**Configuration errors** — Missing required settings, malformed config files at startup","**Fatal security violations** — Authentication bypass attempts, tampered data"],"title":{"icon":"AlertCircle","text":"Use Exceptions For","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**User input validation** — Invalid email format, weak password, missing fields","**Business rule violations** — Insufficient funds, expired subscription, quota exceeded","**Expected external failures** — Network timeout, service unavailable, rate limited","**Not-found conditions** — User doesn't exist, record deleted, cache miss","**Partial success** — Some items processed, some failed"],"title":{"icon":"CheckCircle","text":"Use Error States For","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"AlertCircle","title":"The Java Checked Exception Mistake","content":"Java attempted to get the best of both worlds with checked exceptions — exceptions that must be declared and handled. In practice, this led to verbose code, exception swallowing, and the catch-and-rethrow-as-runtime pattern. Modern languages learned from this: use real exceptions for exceptional cases, and explicit value types for expected failures.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"hidden-control-flow","title":"The Hidden Control Flow Problem","content":[{"data":{"content":"One of the most significant criticisms of exceptions is that they create **hidden control flow**. When reading code, you cannot easily determine which statements might transfer control elsewhere.\n\nConsider this seemingly innocent function:"},"type":"text"},{"data":{"fileName":"hidden_control_flow","languages":[{"code":"public class TransferService {\n public void transferMoney(Account from, Account to, Money amount) {\n // Acquire locks in consistent order to prevent deadlock\n Lock fromLock = lockManager.acquire(from);\n Lock toLock = lockManager.acquire(to);\n \n try {\n from.debit(amount); // Can this throw?\n to.credit(amount); // Can this throw?\n \n auditLog.record(from, to, amount); // Can this throw?\n notificationService.notify(from.getOwner(), \"Transfer complete\");\n } finally {\n toLock.release();\n fromLock.release();\n }\n }\n}","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"**The hidden dangers:**\n\n1. If `from.debit(amount)` throws, the money wasn't debited but locks are released correctly. ✓\n\n2. If `to.credit(amount)` throws, the money was debited from `from` but never credited to `to`. The system is in an **inconsistent state**. ✗\n\n3. If `auditLog.record()` throws, the transfer succeeded but wasn't logged. Might be okay, might violate compliance. ?\n\n4. If `notificationService.notify()` throws, the transfer succeeded but user wasn't notified. Probably fine. ?\n\nWithout examining every method's implementation (and its transitive dependencies), you cannot know which lines might throw. This makes reasoning about correctness extremely difficult."},"type":"text"},{"data":{"fileName":"explicit_control_flow","languages":[{"code":"$7e","label":"Rust","value":"rust"}]},"type":"code"},{"data":{"icon":"Info","title":"Locality of Reasoning","content":"Error states enable 'local reasoning' — you can understand what a piece of code does by looking at it, without needing to chase exception specifications through the entire call graph. This property is especially valuable in large codebases where one person can't know everything.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"testing-benefits","title":"Error State Benefits for Testing","content":[{"data":{"content":"Error states as explicit values provide significant testing advantages over exceptions:\n\n**1. Error cases are first-class test subjects**\n\nWith error states, you can write standard unit tests that assert on error values:"},"type":"text"},{"data":{"fileName":"testing_error_states","languages":[{"code":"$7f","label":"Rust","value":"rust"},{"code":"$80","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"items":["**No special exception handling in tests** — Tests are simple assertions on return values, not try-catch blocks expecting specific exception types.","**Error values are inspectable** — You can assert on error messages, codes, and nested data without string-matching exception messages.","**Composable test utilities** — Helper functions can return Result types, making test setup easier to compose.","**Property-based testing friendly** — Error states work naturally with property-based testing frameworks.","**Better IDE support** — Type-aware IDEs can autocomplete error cases in test assertions."],"title":"Testing Advantages of Error States","variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":6},{"id":"language-support","title":"Language Support Landscape","content":[{"data":{"content":"Different programming languages take different stances on error handling. Understanding the landscape helps you apply appropriate patterns in your chosen language:"},"type":"text"},{"data":{"rows":[["**Rust**","Result","panic! for fatal errors","Result is the default; exceptions don't exist"],["**Haskell**","Either a b, Maybe a","Exceptions possible but discouraged","Strong functional tradition with monadic error handling"],["**Go**","Multiple returns (val, error)","panic/recover for truly exceptional cases","Explicit but verbose; no generics until recently"],["**Kotlin**","Exceptions (default)","Result, sealed classes","Result gaining adoption; Arrow library for functional patterns"],["**Swift**","Exceptions (throws)","Optional, Result","Swift 5 added Result; throws requires explicit handling"],["**TypeScript**","Exceptions (from JS)","Discriminated unions, Result types (library)","neverthrow, fp-ts libraries provide Result types"],["**Java**","Checked + Runtime Exceptions","Optional, Vavr's Either/Try","Checked exceptions often avoided; Optional for nulls"],["**Python**","Exceptions","returns library, custom implementations","Optional type hints don't prevent runtime errors"],["**C#**","Exceptions","Nullable reference types, OneOf library",".NET ecosystem favors exceptions; functional libraries exist"]],"caption":"Error Handling Approaches by Language","headers":["Language","Primary Mechanism","Secondary/Alternative","Notes"]},"type":"table"},{"data":{"icon":"Sparkles","title":"The Rust Influence","content":"Rust's success with Result as the primary error handling mechanism has influenced many other languages. Kotlin, Swift, and even Java are adding or improving result type support. The 'make errors unignorable' philosophy is gaining traction across the industry.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Choosing Your Error Strategy","content":[{"data":{"content":"The distinction between error states and exceptions is not merely syntactic preference—it's a fundamental design choice with far-reaching consequences for code clarity, safety, and maintainability."},"type":"text"},{"data":{"type":"ordered","items":["**Exceptions and error states serve different purposes** — Exceptions are for exceptional, often unrecoverable situations. Error states are for expected, recoverable failure modes.","**Error states make failures visible in the type system** — The compiler ensures you handle failures; silent ignoring becomes impossible.","**Hidden control flow is a real problem** — Exceptions can make code behave unexpectedly; error states make every failure point visible.","**Semantic appropriateness matters** — Match your error mechanism to failure semantics: expected failures deserve error states; programming errors warrant exceptions.","**Testing is easier with error values** — Assertions on values are simpler and more expressive than try-catch blocks in tests.","**Modern languages are converging** — Result types are becoming standard across languages, even those traditionally exception-focused."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand the philosophical and practical distinction between error states and exceptions, we'll dive deep into the **Result/Either type pattern** — the primary tool for representing success or failure as explicit values. You'll learn the full API surface of Result types, composition patterns, and idiomatic usage across different languages."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Foundation Established","content":"You now understand the fundamental distinction between exception-based and value-based error handling. This foundation prepares you for mastering Result types, Option types, and the sophisticated composition patterns that make functional error handling so powerful.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_67bd2164687de4c98bbfb2eb14f91cd2","title":"Result/Either Type Pattern","order":1,"content":null,"isLocked":true},{"id":"seed_37ba2a11036b0b1c307af4ac16f544cd","title":"Option/Maybe Type Pattern","order":2,"content":null,"isLocked":true},{"id":"seed_15d08be86cdd85a4f13ffcc7e460b501","title":"When to Use Result Types","order":3,"content":null,"isLocked":true}]}}