Received: by 10.52.179.135 with SMTP id dg7mr15991942vdc.6.1332768857120; Mon, 26 Mar 2012 06:34:17 -0700 (PDT) X-BeenThere: framework-one@googlegroups.com Received: by 10.52.116.42 with SMTP id jt10ls2318460vdb.4.gmail; Mon, 26 Mar 2012 06:34:16 -0700 (PDT) Received: by 10.52.75.101 with SMTP id b5mr815493vdw.16.1332768856376; Mon, 26 Mar 2012 06:34:16 -0700 (PDT) Date: Mon, 26 Mar 2012 06:34:15 -0700 (PDT) From: Dave Merrill To: framework-one@googlegroups.com Message-ID: <1351473.183.1332768855731.JavaMail.geo-discussion-forums@vbuc18> In-Reply-To: References: <29839218.584.1332683894671.JavaMail.geo-discussion-forums@vbtv42> Subject: Re: [framework-one] Handling service errors MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_181_30107555.1332768855729" ------=_Part_181_30107555.1332768855729 Content-Type: multipart/alternative; boundary="----=_Part_182_16855953.1332768855730" ------=_Part_182_16855953.1332768855730 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks Sean, that's what I ended up doing, using DI/1 for services, only, letting the framework manage controllers, calling services explicitly from the controller. It's working well. Thanks again, Dave On Monday, March 26, 2012 1:22:39 AM UTC-4, Sean Corfield wrote: > > On Sun, Mar 25, 2012 at 6:58 AM, Dave Merrill wrote: > > I have a controller method that calls fw.service('myservice') to perform > an > > action. Since the action doesn't have any result to display, the > controller > > then explicitly calls setView() to (re)render a section index page with > an > > "action completed" msg. I've also tried using fw.redirect() in place of > > setView, to render the index page in a separate request. > > Bear in mind that queues the service to be executed after the > controller completes. > > > The problem is that when FW1 catches an exception in the service call, > the > > explicitly requested view or redirect is still displayed, not main.error. > > I'm not sure whether I'd consider that a bug or not. You can easily > "fix" it by calling setView("main.error") in your main.error handler. > > > You can't catch the service error in your controller, because > > the framework catches and handles it first > > You can't catch it in your controller because the controller completes > before the service executes. If you manage services directly and call > them explicitly, you can catch such errors of course. > > > How would folks suggest handling this? The only idea I had was to not use > > fw.service(), but instead get the service component and make the call to > it > > myself. > > That would be my approach. If the service throws an exception, FW/1 > will invoke main.error - with the default view at this point. > -- > Sean A Corfield > > On Monday, March 26, 2012 1:22:39 AM UTC-4, Sean Corfield wrote: > > On Sun, Mar 25, 2012 at 6:58 AM, Dave Merrill wrote: > > I have a controller method that calls fw.service('myservice') to perform > an > > action. Since the action doesn't have any result to display, the > controller > > then explicitly calls setView() to (re)render a section index page with > an > > "action completed" msg. I've also tried using fw.redirect() in place of > > setView, to render the index page in a separate request. > > Bear in mind that queues the service to be executed after the > controller completes. > > > The problem is that when FW1 catches an exception in the service call, > the > > explicitly requested view or redirect is still displayed, not main.error. > > I'm not sure whether I'd consider that a bug or not. You can easily > "fix" it by calling setView("main.error") in your main.error handler. > > > You can't catch the service error in your controller, because > > the framework catches and handles it first > > You can't catch it in your controller because the controller completes > before the service executes. If you manage services directly and call > them explicitly, you can catch such errors of course. > > > How would folks suggest handling this? The only idea I had was to not use > > fw.service(), but instead get the service component and make the call to > it > > myself. > > That would be my approach. If the service throws an exception, FW/1 > will invoke main.error - with the default view at this point. > -- > Sean A Corfield > > ------=_Part_182_16855953.1332768855730 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Sean, that's what I ended up doing, using DI/1 for services, only, l= etting the framework manage controllers, calling services explicitly from t= he controller. It's working well.

Thanks again,
Dave

On Monday, March 26, 2012 1:22:39 AM UTC-4, Sean Corfield wro= te:
On Sun, Mar 25, 2012 at 6:5= 8 AM, Dave Merrill wrote:
> I have a controller method that call= s fw.service('myservice') to perform an
> action. Since the action do= esn't have any result to display, the controller
> then explicitly ca= lls setView() to (re)render a section index page with an
> "action co= mpleted" msg.  I've also tried using fw.redirect() in place = of
> setView, to render the index page in a separate request.

Bear = in mind that queues the service to be executed after the
controller comp= letes.

> The problem is that when FW1 catches an exception in the = service call, the
> explicitly requested view or redirect is still di= splayed, not main.error.

I'm not sure whether I'd consider that a bug= or not. You can easily
"fix" it by calling setView("main.error") in you= r main.error handler.

> You can't catch the service error in your = controller, because
> the framework catches and handles it first

<= p>You can't catch it in your controller because the controller completesbefore the service executes. If you manage services directly and call
t= hem explicitly, you can catch such errors of course.

> How would f= olks suggest handling this? The only idea I had was to not use
> fw.s= ervice(), but instead get the service component and make the call to it
= > myself.

That would be my approach. If the service throws an exce= ption, FW/1
will invoke main.error - with the default view at this point= .
--
Sean A Corfield 

=


On Monday, March 26, 2012 1:22:39 AM UTC-4, Sea= n Corfield wrote:
On Sun, Mar 2= 5, 2012 at 6:58 AM, Dave Merrill wrote:
> I have a controller me= thod that calls fw.service('myservice') to perform an
> action. Since= the action doesn't have any result to display, the controller
> then= explicitly calls setView() to (re)render a section index page with an
&= gt; "action completed" msg.  I've also tried using fw.redirect()&= nbsp;in place of
> setView, to render the index page in a separate re= quest.

Bear in mind that queues the service to be executed after the
c= ontroller completes.

> The problem is that when FW1 catches an exc= eption in the service call, the
> explicitly requested view or redire= ct is still displayed, not main.error.

I'm not sure whether I'd consi= der that a bug or not. You can easily
"fix" it by calling setView("main.= error") in your main.error handler.

> You can't catch the service = error in your controller, because
> the framework catches and handles= it first

You can't catch it in your controller because the controlle= r completes
before the service executes. If you manage services directly= and call
them explicitly, you can catch such errors of course.

&g= t; How would folks suggest handling this? The only idea I had was to not us= e
> fw.service(), but instead get the service component and make the = call to it
> myself.

That would be my approach. If the service = throws an exception, FW/1
will invoke main.error - with the default view= at this point.
--
Sean A Corfield

------=_Part_182_16855953.1332768855730-- ------=_Part_181_30107555.1332768855729--