Menu
▾
▴
Re: [Springframework-rcp-dev] Bean methods that throw exceptions?
|
From: Jan H. <jh...@sc...> - 2008-01-30 10:30:08
|
Volunteers? Ok, pick a number between 1 and 10 ... :)
Just to inform you: Lieven (a co-worker) will try to write something
about the rules. I'm struggling with a quick start and some more info on
the formModel/valueModel stuff.
I'll probably send a status mail later this evening concerning the
things we still need to do (issues) and the upcoming release.
Kind Regards,
Jan
On Wed, 2008-01-30 at 11:16 +0100, Peter De Bruycker wrote:
> agreed. Any volunteers? ;-)
>
> On 1/30/08, Jan Hoskens <jh...@sc...> wrote:
> I would think that the blog is exactly for that purpose:
> showing a
> specific example of how to work with converters. The converter
> mechanism
> should however be a part of the manual. Possibly with an
> example which
> might be the same as on the blog but preferably not.
>
> Kind Regards,
> Jan
>
> On Wed, 2008-01-30 at 10:55 +0100, Peter De Bruycker wrote:
> > Indeed, I could add you as a writer, however I think it'd be
> better if
> > this stuff is put into the reference manual.
> >
> > WDYT?
> >
> >
> > On 1/30/08, Jan Hoskens <jh...@sc...> wrote:
> > Normally when any Exception pops up during the
> setting of a
> > value, the
> > exception is caught by the
> > DefaultFormModel.ValidatingFormValueModel
> > class and transformed to a bindingError. So if you
> get a error
> > in your
> > message area, it probably came from there. Note that
> there are
> > some
> > issues here: all listeners attached to the value
> change may
> > also throw
> > exceptions that are handled in the same manner. I
> did suggest
> > a change
> > here to provide an explicit binding exception that
> can be
> > thrown in the
> > accessStrategy to separate the good from the bad (so
> to
> > speak). Normally
> > this error should disappear if the value being set
> doesn't
> > generate any
> > exception. Does this work as expected?
> >
> > The getting of a value is another story. I don't
> think any
> > handling is
> > available at that point so an exception will
> probably be
> > caught by the
> > ExceptionHandler that you provide in your context.
> >
> > The developer blog was started by Peter. He could
> add you as a
> > writer to
> > the blog or we could post it in your name after a
> quick
> > review. It would
> > be nice to see some more stuff explained there.
> >
> > Additionally I've checked your project's website. It
> seems to
> > be open
> > source so I'm thinking of checking it out. It would
> be easier
> > to
> > actually see the problem than to write about it. I
> guess this
> > isn't a
> > problem?
> >
> > Kind Regards,
> > Jan
> >
> > On Wed, 2008-01-30 at 11:27 +0200, Rogan Dawes
> wrote:
> > > Geoffrey De Smet wrote:
> > > > Forms are ussually meant for domain objects or
> transfer
> > objects.
> > > > Just like it's pretty impossible to try to
> jpa-persist a
> > (heavy)
> > > > business service or DAO instance.
> > > >
> > > > Wouldn't the use case you describe be better off
> if you
> > > > initialize the encodedBody before showing the
> form?
> > > >
> > > > With kind regards,
> > > > Geoffrey De Smet
> > >
> > > Let me give some more detail:
> > >
> > > This is for WebScarab-NG, which is an HTTP testing
> tool
> > (including an
> > > intercepting proxy).
> > >
> > > What I am modeling here is the HTTP Message
> (Request or
> > Response), with
> > > the following properties:
> > >
> > > "startLine" ("GET http://example.com HTTP/1.0" or
> "HTTP/1.0
> > 200 ok")
> > > "headers" (NamedValue[])
> > > "rawBody"
> > > "decodedBody"
> > >
> > > "decodedBody" is the result of applying the
> various
> > transforms listed in
> > > the "headers" (e.g "Transfer-Encoding: chunked" or
> > "Content-Encoding:
> > > gzip") to "rawBody". I don't actually store
> "decodedBody",
> > but rather
> > > update "rawBody" by applying the various
> transforms.
> > Unfortunately, the
> > > process of applying the transforms can generate
> > IOExceptions, since I
> > > push the data through (Input|Output)Streams such
> as
> > GZIPInputStream.
> > >
> > > So, the idea is that the user can edit various
> properties of
> > the HTTP
> > > message before sending the message to the server,
> and this
> > should
> > > obviously include setting the "rawBody" (if
> desired) or
> > "decodedBody"
> > > (likely easier). Naturally, the two properties
> should remain
> > in sync,
> > > modulo the transforms.
> > >
> > > I have implemented PropertyChangeSupport for this
> object, so
> > various
> > > forms can be notified when the fields they are
> listening to
> > are changed
> > > as a result of other fields being modified. This
> is all
> > working very well.
> > >
> > > The only problem now is what to do when the "(get|
> > set)DecodedBody"
> > > methods throw an Exception. My preference is
> simply to allow
> > the user to
> > > continue editing, with a warning/error message
> until no
> > exception is thrown.
> > >
> > > Thanks for your help.
> > >
> > > Rogan
> > >
> > > P.S. is there an existing place to present the
> results of
> > some of the
> > > advice that I have received on this list? e.g. how
> to do the
> > > Binder/Binding to String<->byte[], how to actually
> bind
> > variables to
> > > JComponents correctly, etc? I don't have my own
> blog
> > (although I did
> > > find http://spring-rich.blogspot.com/)
> > >
> > > >
> > > > Rogan Dawes schreef:
> > > >> Hi folks,
> > > >>
> > > >> I am trying to deal with a derived property
> that can
> > throw an exception
> > > >> when set (or even when "get").
> > > >>
> > > >> The method signature is:
> > > >>
> > > >> byte[] getEncodedBody() throws IOException;
> > > >> void setEncodedBody(byte[] body) throws
> IOException;
> > > >>
> > > >> As suggested, there are some cases where
> invalid data
> > will cause an
> > > >> IOException to be thrown. When this happens, I
> get
> > "methodInvocation"
> > > >> showing up in my form message area.
> > > >>
> > > >> Is there some way of handling this exception,
> and
> > propagating the
> > > >> underlying exception to the user? This appears
> to be
> > handled somewhere
> > > >> in the BeanPropertyAccessStrategy or
> BeanWrapperImpl,
> > although I can't
> > > >> see exactly where.
> > > >>
> > > >> Any ideas?
> > > >>
> > > >> Rogan
> > > >>
> > > >>
> >
> -------------------------------------------------------------------------
> > > >> This SF.net email is sponsored by: Microsoft
> > > >> Defy all challenges. Microsoft(R) Visual Studio
> 2008.
> > > >>
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > >
> > > >
> > > >
> >
> -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Microsoft
> > > > Defy all challenges. Microsoft(R) Visual Studio
> 2008.
> > > >
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > _______________________________________________
> > > > Springframework-rcp-dev mailing list
> > > > Spr...@li...
> > > >
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> > > >
> > > >
> > >
> > >
> > >
> >
> -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio
> 2008.
> > >
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > Springframework-rcp-dev mailing list
> > > Spr...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
> >
> > **** DISCLAIMER ****
> > http://www.schaubroeck.be/maildisclaimer.htm
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio
> 2008.
> >
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
> **** DISCLAIMER ****
> http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ Springframework-rcp-dev mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
**** DISCLAIMER ****
http://www.schaubroeck.be/maildisclaimer.htm
|
