v2: Improve error handling with typed errors and context

[mmcdole]

Overview

Implement a comprehensive error handling system with typed errors that provide context about parsing failures, making debugging easier and enabling better error recovery strategies.

Tasks

Error Types

• Define error types for different failure categories:
  • ParseError - Malformed XML/JSON structure
  • ValidationError - Missing required fields, invalid values
  • NetworkError - HTTP failures, timeouts (already have HTTPError)
  • FormatError - Unknown feed type, unsupported version
  • ExtensionError - Problems parsing extensions

Error Context

• Include parse location (line/column) when available
• Include field/element path that caused error
• Include raw content snippet around error
• Make errors chainable with errors.Is() and errors.As()

Strictness Integration

• Errors should be strictness-aware
• Issues ignored in lenient mode become errors in strict mode

Example Usage

feed, err := parser.Parse(reader, opts)
if err != nil {
    var parseErr *gofeed.ParseError
    if errors.As(err, &parseErr) {
        fmt.Printf("Parse error at line %d: %s\n", parseErr.Line, parseErr.Message)
        fmt.Printf("Context: %s\n", parseErr.Context)
    }
}

Benefits

• Easier debugging with specific error information
• Better error messages for end users
• Programmatic error handling based on error type
• Improved logging and monitoring capabilities

Related Issues

• Part of v2 RFC (Roadmap: shipping the v2 value in v1 #241)
• Works with strictness controls (v2: Add parsing strictness configuration #250)

[mmcdole]

When I weighed the breaking changes a v2 would need against just shipping the same value in v1, the case for breaking wasn't strong. Most of what was planned here doesn't need a new major version, so I'm deferring v2 and delivering it in v1 without breaking anyone. A few fields get marked deprecated and we can revisit dropping them in a v2 later.

Ships in v1 as typed errors you can match with errors.As.

Roadmap: #241.