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);
>>>> }
>>>>
>>>>
>>>
>>
>
