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