Spicefactory Forum Index Spicefactory
Forum Archive
 
 SearchSearch    Log inLog in 

MapCommand doesn`t handle errors

 
Post new topic   Reply to topic    Spicefactory Forum Index -> Spicefactory
View previous topic :: View next topic  
Author Message
p.r.i.d.e.



Joined: 16 Apr 2012
Posts: 7
Location: Ukraine

PostPosted: Thu May 10, 2012 3:03 pm    Post subject: MapCommand doesn`t handle errors Reply with quote

Hi Jens,
I don`t know why you avoid my messages, but please take a look to situation with MapCommands.

If I have simple Synchronous or Asynchronous MapCommand than that command doesn`t react to error (there is no error in the logs and no flash error popUp).

you can reproduce it just by adding throw new Error("error); in execute or result method.

At logs I can see next:
Discarding command status error for message '[object ZMessage]': no matching observer
Discarding command status error for message '[object ZMessage]': no matching observer


thanks.
Back to top
View user's profile Send private message
robmcm



Joined: 15 Apr 2011
Posts: 15
Location: London

PostPosted: Thu May 10, 2012 3:38 pm    Post subject: Reply with quote

I have the same issue.

If you use a lagacy command you at least get a log message, but not error thrown.

Any fix would be greatly appreciated.
Back to top
View user's profile Send private message
Jens Halm
Site Admin


Joined: 21 Sep 2007
Posts: 2631
Location: Cologne, Germany

PostPosted: Fri May 11, 2012 7:34 am    Post subject: Reply with quote

1) There are some places where errors are currently not logged. This will be fixed in 3.0.1, but that is still a few weeks away.

2) The RETHROW setting on MessageSettings does not have any influence on command error handling anyway, it was an implementation detail of Parsley 2 that messaging and commands were tightly coupled. This is no longer the case.

3) For now you can use CommandError with a message type parameter of Object to have a single handler that catches all errors. In some cases the bug in 1) might occur so early that this would not work, too, but you can try.

4) You might try to use the search function of this forum, I'm pretty sure this has already been discussed.

5) I'm not avoiding anyone's messages, but obviously cannot guarantee to answer all posts.
_________________
Jens Halm
Spicefactory
Back to top
View user's profile Send private message
p.r.i.d.e.



Joined: 16 Apr 2012
Posts: 7
Location: Ukraine

PostPosted: Fri May 11, 2012 10:37 am    Post subject: Reply with quote

Hi Jens,

Thanks for reply.
Command Error seems enough for me to know what message lead me to error, but unfortunataly an error object doesn`t tell me a lot. At this case I shoud make my own notification popUp and then looking for a real problem iside a command. And that lead me to avoid making some complex logic at resut handler (except converting results for sequense).

I see that you catching errors in commands (AbstractAsyncCommand, ..) and dispatch then CommandResultEvent.ERROR. Maybe it will be good to have possibility to see a stack trace of error.

I will look forward to the release 3.0.1

Thanks
Back to top
View user's profile Send private message
p.r.i.d.e.



Joined: 16 Apr 2012
Posts: 7
Location: Ukraine

PostPosted: Fri May 11, 2012 2:59 pm    Post subject: Reply with quote

We can add workaround to catch CommandResultEvent.ERROR from MapCommand.
Actually we should listen LightCommandAdapter.

I`m making a custom component wich implement RootConfigurationElement (root configuration element in MXML)

Code:

We need to implement process method
public function process(registry:ObjectDefinitionRegistry):void
{
   var lifecycleObservers:LifecycleObserverRegistry = registry.context.scopeManager.getScope(ScopeName.GLOBAL).lifecycleObservers;
   
   lifecycleObservers.addObserver(new DefaultLifecycleObserver(Provider.forInstance(this), "handlePostInit", InitPhase.postInit(), null, ClassInfo.forClass(LightCommandAdapter)));
   lifecycleObservers.addObserver(new DefaultLifecycleObserver(Provider.forInstance(this), "handlePreDestroy", DestroyPhase.preDestroy(), null, ClassInfo.forClass(LightCommandAdapter)));
}


at handlePostInit we add listeners for necessary events, then handle it.
at handlePreDestroy we remove listeners.

Code:

public function handlePostInit(instance:LightCommandAdapter):void
{
...
}


These handlers will be called for each command when command will be configured through own Lifecycle.[/code]
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Spicefactory Forum Index -> Spicefactory All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group