rted the attachment to a web page:
>http://physpics.com/Java/Notes/ExceptionHandling.php
>
>
>
>
>>
>> From: Maruan Sahyoun
>> To: "dev@pdfbox.apache.org"
>> Sent: Sunday, February 16, 2014 3:36 AM
&
ptionHandling.php
>
>
>
>
>>
>> From: Maruan Sahyoun
>> To: "dev@pdfbox.apache.org"
>> Sent: Sunday, February 16, 2014 3:36 AM
>> Subject: Re: [DISCUSS] PDFBox and Exception handling
>>
>>
>> Hi Fred,
>>
>> unfortunately th
I've converted the attachment to a web page:
http://physpics.com/Java/Notes/ExceptionHandling.php
>
> From: Maruan Sahyoun
>To: "dev@pdfbox.apache.org"
>Sent: Sunday, February 16, 2014 3:36 AM
>Subject: Re: [DISCUSS]
Hi Fred,
unfortunately the attachment didn't make it through due to restrictions of the
mailing list - could you make it available somewhere on a public site?
BR
Maruan Sahyoun
> Am 16.02.2014 um 01:04 schrieb Fred Hansen :
>
>
> Just in case you're not tired of exceptions, I've written the
Just in case you're not tired of exceptions, I've written the attached. It
concludes that the right-thing-to-do is to examine individually each throw
statement.
Maruan
> On 14 Feb 2014, at 00:43, Maruan Sahyoun wrote:
>
> John,
>
>
>> Am 13.02.2014 um 21:57 schrieb John Hewson :
>>
>> Maruan
>>
>> I’ve given this some considerable thought and realised that while it may
>> technically work, it won’t be maintainable.
>>
>>> the user is making use of
John,
Am 13.02.2014 um 21:57 schrieb John Hewson :
> Maruan
>
> I’ve given this some considerable thought and realised that while it may
> technically work, it won’t be maintainable.
>
>> the user is making use of PDFBox because they don’t want to have to parse
>> the PDF file themselves.
>
Maruan
I’ve given this some considerable thought and realised that while it may
technically work, it won’t be maintainable.
> the user is making use of PDFBox because they don’t want to have to parse
> the PDF file themselves.
>>
>> But in case a file is invalid for whatever reason the only
John
Am 13.02.2014 um 18:50 schrieb John Hewson :
> Maruan,
>
>> Now let’s assume there is a situation where an object is not at a certain
>> location, or a specific string is missing …. what if we throw an exception
>> where one could register a handler. We pass some kind of context e.g. lexe
Maruan,
> Now let’s assume there is a situation where an object is not at a certain
> location, or a specific string is missing …. what if we throw an exception
> where one could register a handler. We pass some kind of context e.g. lexer,
> file position, token …. and the user can handle the e
Hi John,
currently pdfbox mostly throws IOExceptions where the user of the lib is not
able to do something about it.
Some of these exceptions could occur because a file was not found etc. So
that’s ok. Others might occur because objects are not at a certain position.
There are workarounds for
I'm not sure in understand what you mean, the Camel examples are very complex
indeed. A quick concrete example of what you're after would help greatly.
-- John
> On 13 Feb 2014, at 00:20, Maruan Sahyoun wrote:
>
> Hi,
>
> what do you think of having an exception handling in pdfbox where peopl
Hi,
what do you think of having an exception handling in pdfbox where people could
define their own handlers. Something similar to
https://camel.apache.org/exception-clause.html
The benefit would be that we could pass the context e.g. during PDF parsing and
the handler could return something w
13 matches
Mail list logo
