Hi All, I see two paths:
(1) All these APIs (if they are indeed needed, are they?) could throw both IOException and ParseException (assuming you want to keep ParseException a direct subclass of ParseException). My reasoning here is that the underlying code like a Jackson Object Mapper may have a genuine IOException even when parsing a String or byte[]. How? Because the underlying gadget that does the parsing, might need to do some IO to configure itself or who knows what. (2) Another route is for all APIs to only throw ParseException and have the internals catch everything and rethrow a ParseException. That might be simpler and more homogeneous. Gary On Mon, Jul 24, 2017 at 1:34 PM, Mikael Ståldal <[email protected]> wrote: > I could use "Throwables.rethrow(e)", but is that really better than "throw > new RuntimeException(e)"? > > > > On 2017-07-24 22:06, Matt Sicker wrote: > >> Java 8 added an UncheckedIOException class which is handy for rethrowing >> IOException. Since we're on 7, that class isn't available. However, if you >> just want to throw it, you can use the rethrow() method in Throwables >> which >> won't wrap the exception (abuses type erasure to allow checked exceptions >> to be thrown). >> >> On 24 July 2017 at 14:56, 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); >>>> } >>>> >>>> >>> >> >> >
