On Mon, Mar 10, 2008 at 10:21 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin wrote: > > > I think that I'd rather we follow the example of other > > getInputStream/getReader exemplars, and throw > > java.io.UnsupportedEncodingException if it is called on a type for which > a > > Reader is not appropriate. > > > in the end, i decided that consistency was more important and elected > > to throw the appropriate exception. > > Consistency with what?
the rest of the pull parser > > i don't really like having to catch runtime exceptions > > Perhaps that's why the Servlet and Portlet APIs declare > UnsupportedEncodingException and IOException instead of > UnsupportedCharsetException or IllegalCharsetNameException? I'd have to > check the code to see if they actually catch the latter, and return the > former, or if they just allow them to leak out undeclared. IIRC UnsupportedCharsetException and or IllegalCharsetNameException were introduced with nio i've used both approaches to exceptions (bio and nio) quite a bit now and i think that i prefer nio. when i specify a charset which i know is gauranteed to be present then it's a PITA to have to handle that exception. occasionally, i may need to use a variable charset and then i just have to catch the runtime. > > > If I asked you to search > > > for SOMETEXT, what do I get back? I might want a collection of [part, > > > first_offset]-tuples. Less than that, and you would be discarding > > > information that you should already have, more than that and I would be > > > forcing you to do extra work that a given use case might not require. > On > > > the other hand, perhaps I just want to know about the first part in > which > > > you find it, not all parts containing it. And can I ask that you search > > > only headers or parts of only certain content-type(s)? > > > > > > Point being that, yes, I'd like to have a search functionality, but I'd > like > > > some discussion over the interface and supported use cases. And if we > don't > > > build this into an existing class, it could be a shared utility, rather > than > > > leaving it as just an example for people to clone. > > > (as jukka posted) given getReader search is just a trivial pull parser > > application. definitely not worth a major design exercise. probably > > best as a worked example somewhere in the documentation. > > I suspect that it will have a lot more utility than that. Mailets will want > to search for text within the message structure. but there's a balance between utility and simplicity. text searching is now a simple application of the library. better just to give a worked example in the documentation and then think about whether including a simplified email-only interface as a mailet utility would be worthwhile. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
