The caller will get an unexpected unchecked exception in the alternative scenario as well.
Anyways, it might not be a terrible idea to use checked exceptions deriving from IOException in this API. On 25 July 2017 at 02:49, Mikael Ståldal <[email protected]> wrote: > Right, but this one will not: > > public LogEvent parseFrom(InputStream input) throws IOException, > ParseException { > return objectReader.readValue(input); > } > > > In any case I need to translate from Jackson's JsonProcessingException to > our ParseException. > > > > On 2017-07-24 22:44, Gary Gregory wrote: > >> On Mon, Jul 24, 2017 at 1:31 PM, Mikael Ståldal <[email protected]> wrote: >> >> The code you posted will never throw ParseException. >>> >>> >> It sure does! See: >> >> @Override >> public LogEvent parseFrom(byte[] input) throws ParseException { >> try { >> return objectReader.readValue(input); >> } catch (IOException e) { >> throw new ParseException(e); >> } >> } >> >> @Override >> public LogEvent parseFrom(byte[] input, int offset, int length) >> throws >> ParseException { >> try { >> return objectReader.readValue(input, offset, length); >> } catch (IOException e) { >> throw new ParseException(e); >> } >> } >> >> >> >>> Yes, ParseException could extend IOException, but I would still have to >>> do >>> translation. >>> >> >> >> Translate from what to what? From one of kind of IOException to another >> kind of IOException? >> >> Gary >> >> >> >>> >>> On 2017-07-24 22:20, Gary Gregory wrote: >>> >>> Whaaaat? Note that the code I posted here compiles just fine. A >>>> JsonProcessingException >>>> is already a subclass of IOException. Wrapping >>>> JsonProcessingException >>>> in >>>> a ParseException is just adding a level of indirection for which I see >>>> no >>>> point, especially when the methods already throw IOException. >>>> >>>> As a side note, why can't ParseException extend IOException? You parse >>>> some >>>> kind of _input_, parsing does not happen in a void. >>>> >>>> Gary >>>> >>>> On Mon, Jul 24, 2017 at 12:56 PM, Mikael Ståldal <[email protected]> >>>> wrote: >>>> >>>> But that won't work, I need to at least translate >>>> JsonProcessingException >>>> >>>>> (Jackson specific, which we don't want to expose) to our own >>>>> ParseException. >>>>> >>>>> >>>>> >>>>> On 2017-07-23 22:01, Gary Gregory wrote: >>>>> >>>>> @Override >>>>> >>>>>> public LogEvent parseFrom(InputStream input) throws >>>>>> IOException, >>>>>> ParseException { >>>>>> return objectReader.readValue(input); >>>>>> } >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -- Matt Sicker <[email protected]>
