I created a branch called LOG4J2-1986-b with what I think is a cleaner
implementation.

Gary

On Tue, Jul 25, 2017 at 7:40 AM, Matt Sicker <[email protected]> wrote:

> 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]>
>

Reply via email to