| View previous topic :: View next topic |
| Author |
Message |
alexuhlmann
Joined: 15 Sep 2009
Posts: 7
|
 Posted: Tue Sep 15, 2009 6:31 pm Post subject: Why Are Exceptions behind MessageHandler Code Swallowed? |
 |
|
In DefaultMessageProcessor, I see:
| Code: |
private function invokeMessageTarget (target:MessageTarget) : void {
try {
target.handleMessage(this);
}
catch (e:Error) {
log.error("Message Target threw Error {0}", e);
}
}
|
So, every exception from application code executing behind a method marked with MessageHandler will be swallowed and only logged . What is the motivation behind this general try/catch blog? |
|
| Back to top |
|
 |
Jens Halm
Site Admin
Joined: 21 Sep 2007
Posts: 1498
Location: Cologne Germany
|
| Posted: Tue Sep 15, 2009 7:14 pm Post subject: |
|
|
Well, the original motivation was that one handler should not necessarily be influenced by another failing handler. But it is indeed desirable that developers have more control over error handling. Thus for 2.1 this enhancement ticket already exists:
http://opensource.powerflasher.com/jira/browse/PSL-260
Just happen to work on that right now... 
_________________
Jens Halm
Spicefactory |
|
| Back to top |
|
|
alexuhlmann
Joined: 15 Sep 2009
Posts: 7
|
| Posted: Tue Sep 15, 2009 7:41 pm Post subject: |
|
|
Wow, great timing.  However, I don't fully understand the motivation for this try/catch.
Your workaround with the MessageError tag would be an improvement but AFAIK, it would also require developers to write a MessageError handler for each MessageHandler, wouldn't it? At least, then they are certain that they see exceptions thrown and don't have to watch log files.
What is the extra significance of ensuring other message handlers are executed even if one message handler throws an exception that should alert the developer? Could the developer concerned about handling code, not write their own try/catch behind a MessageHandler? |
|
| Back to top |
|
|
Jens Halm
Site Admin
Joined: 21 Sep 2007
Posts: 1498
Location: Cologne Germany
|
| Posted: Tue Sep 15, 2009 7:55 pm Post subject: |
|
|
No, you don't have to write millions of error handlers, you can match any way you want:
| Code: | [MessageError (type="com.foo.MyMessage")]
public function handleError (processor:MessageProcessor, error:IOError) : void; |
In the first example the error handler would be invoked whenever any handler for a message of type MyMessage throws an IOError.
| Code: | [MessageError]
public function handleError (processor:MessageProcessor, error:Error) : void; |
But now you really have a global handler, for every type of error in any type of handler. This should give you enough flexibility.
I currently see no alternative. Simply letting the Error through wouldn't be an option. Since message handling could happen asynchronously it could be thrown at unexpected places and developers would have even less control. Or did you have something specific on your mind as a solution?
_________________
Jens Halm
Spicefactory |
|
| Back to top |
|
|
alexuhlmann
Joined: 15 Sep 2009
Posts: 7
|
| Posted: Thu Sep 17, 2009 9:02 am Post subject: |
|
|
| I see now. Your MessageError tag will solve this very well. Thanks for your replies! |
|
| Back to top |
|
|
verveguy
Joined: 22 Sep 2009
Posts: 30
Location: Raleigh, NC
|
| Posted: Tue Sep 22, 2009 5:02 am Post subject: Turning on error logging |
|
|
The try/catch/bury behavior is unfortunate in this case, especially for a developer new to parsley trying to figure out how to get things working and adapting older code to fit.
I see your argument, since it's much like the argument Adobe make regarding binding errors: they *mostly* get swallowed, although some do not.
My real problem in this case is that the errors are swallowed *silently*. The log.error() call inside invokeMessageTarget() never produces any output in the default logs, so there's no way for the developer to know that such problems are occurring.
I've been trying to figure out how to change the config to show me these errors in the trace log...with no luck.
If these errors had been logged, it would have saved me some hours poking around and stepping through my code.
Any clues? |
|
| Back to top |
|
|
verveguy
Joined: 22 Sep 2009
Posts: 30
Location: Raleigh, NC
|
| Posted: Tue Sep 22, 2009 5:14 am Post subject: Of course.... |
|
|
Of course, the answer is to simply use standard Flex logging to setup a TraceTarget filtering on org.spicefactory.* classes.
Why did I think it would be harder than that? <sigh> |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
