Currently, ParseException can be thrown in IncrementalIndex.toTimeAndDims() and Aggregator.aggregate() as well as InputRowParser and Parser. This results in callers should handle ParseException whenever calling them. Furthermore, #5418 introduces collecting metrics about errors while ingesting data, and ParseException from diverse places makes it difficult to make a unified metrics collector. This can be especially an issue when a new task type is introduced like in #5492 because we should add metrics collecting codes manually.
This issue can be addressed by allowing ParseException only in InputRowParser and Parser. To do so, we should be able to let them know what are the expected data types. Once InputRowParser returns a valid InputRow, then ParseException shouldn't be thrown because we've already done all parsing error checks.
Currently,
ParseExceptioncan be thrown inIncrementalIndex.toTimeAndDims()andAggregator.aggregate()as well asInputRowParserandParser. This results in callers should handleParseExceptionwhenever calling them. Furthermore, #5418 introduces collecting metrics about errors while ingesting data, andParseExceptionfrom diverse places makes it difficult to make a unified metrics collector. This can be especially an issue when a new task type is introduced like in #5492 because we should add metrics collecting codes manually.This issue can be addressed by allowing
ParseExceptiononly inInputRowParserandParser. To do so, we should be able to let them know what are the expected data types. OnceInputRowParserreturns a validInputRow, thenParseExceptionshouldn't be thrown because we've already done all parsing error checks.