 |
History
| Log In
|
|
|
|
For more details about requirements for having a way to catch errors, see bug
Reopening these bugs that were deferred Minor Enhancements
Can I just point out that this is a pretty huge issue... If my users are experiencing silent runtime errors, I'd like a way to catch those (at least catch anything that wasn't explicitly handled in a try/catch) and log them to my backend. That way I can follow those logs and fix unknown issues that my users may be experiencing.
Would love to have this one as well...
http://clintm.esria.com/2006/12/02/global-exception-error-handling-in-as3/ Add me to the list of people requesting this enhancement. I am wrestling with an EOFError that I can not catch. Ironically, the EOFError is in the Flex code playing H.264 video files.
Every language I've worked with has a way to catch uncaught exceptions. This is huge. I vote for this as well. We need something like Application.onException or something.
We are developing a huge application which we would not be able to wrap every bit of code in a try catch scenario. This is a MUST have for us. For our product its to the point of being critical to be able to prevent the user from seeing any issues/have silent issues. We need to be able to find what caused them and track down the issue. Relying on our customers to tell us what is broken and how they did it is no good! Thanks for the attention on this one!
I am guessing this falls outside of the Flex Framework. Most of the unhandled exceptions happen in other threads like event handlers and response handlers. I do think that it should be possible to catch all exceptions in some place, the player is catching them so there should be some way to have the SystemManager handle them. But other than debugging I don't see a huge advantage to having this feature.
Until Adobe proprietary code is free of bugs, this feature is a must have.
Typically, the Advanced Data Grid component is quite buggy. When hitting such a bug, the user ends with a totally non responsive UI without even knowing that an error occurred. So you end up with users having bad feelings about Flex/AS based applications. Adobe should consider this feature as strategic for the adoption of their AS-based platforms (Flex/AIR). (Or they will soon lose me as Flex evangelist). This is a **Must Have** feature for us. We also are creating a very extensive application (50K lines ot code, 600+ classes, dynamic loading of modules, etc. etc.) and our main customers are children. We already have an extensive infrastructure for providing detailed error reporting from the client to our servers, but can find no way to catch those few nasty, nasty occasional glitches that otherwise silently hang our application. Please, raise the priority of providing this functionality and help all of us developers **make Flash/Flex applications more reliable**. That's good for our customers. Good for us. AND GOOD FOR ADOBE!
This would be a big deal for us as well. Big app, server ready to log a stack trace from difficult-to-reproduce failures, but no good way to catch them.
Putting a try/catch around every entry point is pretty gross, because there are hundreds of entry points in which we'll need to duplicate code. This is also prone to error, because it is difficult to be sure one is hitting every entry point. Unfortunately a try/catch block won't cover 100% of the issues, because if there is an exception that occurs due to a bug in the Flex or AIR components (e.g. moving your mouse cursor over a component causes an exception, which happened a while ago with AIR), you won't be notified that the exception occurred. Instead, you'll just end up seeing bizarre behavior in the application.
I won't repeat previous comments contents but, as many developpers, I think this feature is critical for industrial/professional applications and it could gretly enhance reliability of Flex applications. I vote for this as well...
I really miss this when working in Flex, in all the other languages I've used I've been able to add some sort of catch all for those really un-expected glitches and have some reporting.
With Flex/Flash I have to hope that a user is kind enough to submit a bug report (not good customer service) or that the bug happens to one of our staff members first. Bugs are inevitable in software some way to catch the edge cases which are totally un-expected, recover from them (or at least warn the user that something really bad happened) and more importantly log/report them so that we can work on resolving them is essential. Having worked on (and currently working on) large flex and AIR applications, this is one of those missing features that makes you question ActionScript's readiness for large applications. I don't have any serious complaints about AS, but adding this feature would make a lot of us enterprise developers really happy because it makes it a lot easier to deliver enterprise level applications.
This sounds like a Flash Player required feature/bug rather than a Flex SDK feature, because it affects all AS3 applications, not just Flex/AIR apps.
There are many duplicates of this request, which tells me it is sorely needed. Please link these two as children to this one.
https://bugs.adobe.com/jira/browse/SDK-11199 https://bugs.adobe.com/jira/browse/ASC-3139 There are others, I just haven't added them to my watch list. At a minimum, can't we have it in Astro - pretty please? Thanks! This is extremely important. We built a small prototype which was great, but when we started rolling this out as a large application, we quickly got burried in bugs from the Flex infrastructure.
The advanced data grid is *incredibly* buggy; we get all sorts of asynchronous errors from the managers as well -- i.e. NPE's from tooltipmanager timer, e.t.c; usually these errors result in the UI freezing up and becoming completely unusable. For a large enterprise GUI to freeze up w/cryptic error messages is unacceptable. Frankly I'm surprised this isn't at the top of your list. Without this feature I question whether Flex is ready for large scale apps.. I too would like to echo how mission critical this feature is. Having the ability to track exceptions as users encounter them is vital to keeping our long term sites running smoothly. I agree with Mark DeMichele, something along the lines of Application.onException would be perfect for handing off errors to Splunk.
I don't know what the big deal is -- our code is 100% error-free so we don't have to worry about this problem.
Just kidding, please get this taken care of soon, Adobe! Imho, not need to fix this. It's not a bug.
"Imho, not need to fix this. It's not a bug."
...Which is why it is registered as a Feature Request. This is a standard feature for most languages, the fact that it is not part of flash already is alarming. This really needs to be implemented to support production environments, especially with number of applications built in Flex and Air increasing so quickly.
At IMVU (www.imvu.com) we are porting most of our UI over to Flex, and we've had many user reports of "weird things" intermittently breaking in the field. For example, it looks like the current round of failures is caused by the LayoutManager updateDisplayList phase no longer running. We would save weeks of investigation time if we could log uncaught exceptions.
This is the largest issue with our adoption of Flex. I think this feature sshould have a higher priority because any serious framework should provides a way to manage exceptions at the root level.
This certainly needs to be addressed. It is very difficult to catch every event error manually. We need a global catch, which will also allow people to integrate exceptions with enterprise logging if your company uses it. The system exception, is very unfriendly looking and when it occurs makes the code look sloppy. We need to be able to throw a custom error globally to the user, and give the developer the info of what went wrong. This could happen with a global catch.
With more and more enterprise/production level applications being written in Flex/AIR this is really a must have. It's simply unacceptable to have let this founder for over a year when Adobe is trying to convince companies to use these technologies for application deployment. Especially with state-dependent applications like will be developed with CoCoMo and other such services that are forthcoming, having a way to report RTEs to developers as customers experience them, with detailed stack traces and useful debugging information, is incredibly important and shouldn't be ignored.
I don't know how this has a lower priority than say, PixelBender functionality. While it's not SNAZZY, it's virtually impossible to write an enterprise quality application that has application controlled unexpected error handlers for when those unexpected errors happen that should be emailed/logged to the server with a bunch of other data. Unless, of course, Adobe thinks the design pattern around this is to put a try/catch statement in every method...
There's obviously some sort of standard handler in there for the debug version of the player. Expose that as some form of event, and viola.... Adobe, I hope you are listening and devoting substantial resources to solving this issue, because nothing less that the stability of the Flash platform is at stake here.
Please do not underestimate the importance of solving this issue. When the best Flex developers can't deploy and run an enterprise-deployed Flex app without the possibility of it freezing unexplainedly to the end user or wihout a fatal exception dialog in the debug player is installed, something has to be done. The ability to catch these exceptions and handle them by the application needs to be present. Only certain rare security exceptions should be uncatchable to prevent abuse, and even then, and they are a mere fraction of uncaught exceptions that can occur. BIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIG bug !!!
or HUUUUUUUUUUUUUUUUUUUGE Feature request !!! Adobe's developpers don't understand this. Maybe because all of their applications are so bugged that a "not catchable exception" popup is usual... :-D Piling on with everyone else. Please do something about this.
Can you hear me, Major Tom? Can you hear me, Major Tom? This is absolutely absurd that this feature wasn't included in FP10. Uncaught exceptions are cornerstone of enterprise application development. This feature was included in the first release of SilverLight / WPE due to it's importance. Cmon Adobe, please help the developers that are trying to push your tech as a serious leader!
I'll settle for it being in the next dot release of FP10. Considering that nothing less than the stability of the Flash Platform is at stake, I would like to see the Flash Player and Flash Platform Teams make this their top priority, over and above any new features.
I'm not going to repeat previous comments but this is a must for big apps, our application will switch to production soon, and we will not be able to track any possible errors if there is no way to trap unhandled exceptions.
For everyone on here that would like a workaround until this issue is resolved and is using Flex Builder, you can use the Profiler.
All that you need to do is create a memory snapshot before the error, and then one after the error, then select both of the snapshots and click "Loitering Objects". Sort the list by Object and find all of the objects that have Error in the name (in my case it was TypeError). Double click on the row and it will open into the "Object References" view where you can click on the instance(s) and see the Allocation Trace. This should get you to the exact line in your code that is causing the problem. Hope this helps someone else. @Kristen:
I think you are misinformed to what this issue is. Let me describe to you the scenario: You have created an application and released it for use, but there are bugs in it. These bugs cause the application to crash. The crash occurs silently for all end-users (esp. if this application is an AIR app). The application continues executing but now things are going wrong and the users complain to us (the developers). Since we have no way of knowing when/how the error occured, we cannot fix the issue. If we had a way to handle errors at the application level, we could provide ourselves more information and therefore be able to pinpoint and solve the issue causing the error. This is a big deal and I hope it's addressed soon. It is quite embarrassing to get bug reports from end users and you have no way to ascertain what the problem might be.
I've been a C# developer for years and global exception handling is just part of the base package. I'd never imagine that this wouldn't be part of any modern framework. Please, Adobe. It's been well over a year and a half. Are we going to see any movement on this? I just wanted to add my vote for this fundamental enterprise feature. Perhaps this is something that ActionScript should support beneath flex. Either way, the lack of this feature makes it much more complicated to develop and test reliable code for industrial applications.
This issue is now the issue most voted on, and still this is at one of the lowest priorities?
Please get going, this is getting silly. 'Perhaps this is something that ActionScript should support beneath flex.'
Since the Flex compiler takes your source and turns it in to other source and then compiles it, I personally think this should be a feature of Flex rather than ActionScript though without knowing the intricacies, I suspect a corresponding change would need to be made to Flash Player as well. In my view a simple errorHandler property (of type function) on mx:Application which is called with any uncaught exceptions would do me fine. In a pure ActionScript program (which may not be a Flex app) it would be hard to define where a global error handler could be appropriately defined. At least if it is defined as part of a Flex application it is pretty clear cut and solves the problem for most people watching this issue (I suspect). But you're right, however this is done, this is a severely needed feature. Adobe, please fix this ASAP. Flex is great. But this is one of the biggest oversights you've made with it.
Please create ability to load custom class before loading application.
Then this problem can be solved for example like this. Set at config file the main loading file as Bootstrap.as Bootstrap.as public class Bootstrap { public function Bootstrap() { try { var application:Applicaiton = new MyApplication(); // any exception that occured at application will be catched } catch (Error) { // show "Unexpected error occured" window with ability to send some info like "stack trace" to the server or by email... } } } @Zinovii Dmytriv:
You could do that already, but it's not going to help you unless your Error occurs within the constructor of MyApplication. If you're advocating that Adobe creates a special circumstance where try/catch gets extra magic and doesn't behave the same as everywhere else, well... that is just a really bad idea, since it introduces inconsistency and confusion in the language where none should exist. Also, that solution wouldn't do anything to intercept unhandled ErrorEvents, which aught to also be possible (since the debug player will throw alerts at you if you don't have any event listeners on an ErrorEvent). What I believe we should really hope to see is the creation of some properties for instances of ApplicationDomain (ApplicationDomain.errorHandler and ApplicationDomain.errorEventHandler would probably be good), which can then be set to a callback function(e:Error):void / function(e:Event):void that gets used for all unhandled errors within the given ApplicationDomain. Doing it this way instead of using a static global property (like System.errorHandler or similar) gives a little extra flexibility if you would want to handle errors caused by included SWFs separately from errors that occur within the root application. (Unless anyone else has a reason why this would also be bad and can suggest something better, of course...) I am actually surprised viewing this Adobe disregard.
Direct competitors from community and industry offer several alternatives and we are really dissatisfied with the "Adobe way". Please comment this issue in order to make Adobe take a decision. If they (Abobe) have a problem with that, they should ask the community looking for solutions, don´t they? Thanks in advance HUGE issue for any serious application.
Big enough for me to start considering alternatives for my next projects, i.e. SilverLight (unfortunate because I'm no Microsoft fan, but sorry Adobe, this feature is a must have). The priority was changed to A and than to C :(
PS Please bear in mind, that every time Flash Player throws an uncaught exception, God kills a kitten!!! (c) They don't seem to grasp the importance... flash player developers understandably
care more about cute graphics and animation than providing RIA programmer support. It is the Flex community who is suffering here, shouldn't this bug be on the radar of Flex developers ? With a fix in Flex framework ? Adobe, PLEASE have the Flash Player team make this their NUMBER ONE PRIORITY. Of course we don't know why it has been demoted to C. It could be that in order to implement this, they've got to monkey around with other things and get them done first. But the change doesn't bode well, cause we have no idea what's happening internally at Adobe.
Adobe, I think we need to hear from someone that you're hearing us, the same way that the Flex team communicated with the community on the Fx Prefixing issue. THIS IS NOT A FLEX ISSUE. This is a stability-of-the-Flash-Platform-itself issue. And it affects all Adobe developers, whether you build banner adds or enterprise RIAs -- it all goes to the Flash Player. Adobe, tell us you're on this, you're looking into it, you're implementing it, and it'll be in Flash Player 11, or better yet, a point-release of Flash Player 10/AIR 1.5. That's what we want, and expect to hear. A lot is at stake here. We cannot state it clearly enough. I love Flash. I don't want to learn Silverlight in a year cause Adobe didn't make the Flash Player robust enough for growing needs. I think, that Adobe developers are too week to solve this problem, because these errors are "unexcepted" even for them ;)
"The priority was changed to A and than to C"
I think, if I'm reading this right, the priority we see has always been 'C'. The update added an internal priority field (which was previously blank) set to 'A'. I don't think the internal priority field is shown on the main screen (being internal). It would be nice to have an official comment on whether the priority changed and what the plans are, if any, since so many people are interested in this. I also wanted to throw my voice in support of this issue, we're working on developing a Flex app now and I'm praying this is fixed before we go to production, otherwise I'm afraid debugging production issues is going to be a nightmare. Well, that will be very helpful on flexmojos unit test support either.
So far, in some situations the test just stop and users have no idea what is going on. I'm working that around with timeout, if tests don't finish in 2 minutes they are considered fail and FP will be forced to close. VELO Here's a couple reasons why this might be a good idea,
http://www.flexcapacitor.com/temp/AdobeTV_1.png http://www.flexcapacitor.com/temp/AdobeTV_2.png test it now, http://tv.adobe.com/ If you're interested in fixing the specific error above vote for it here, https://bugs.adobe.com/jira/browse/FP-141 Is there some way to globally replace a piece of the application-wide UI event dispatching so we can then override addEventHandler or something else that sees all the UI event callbacks? This would be the ideal place to splice in another layer of function with a try/catch to get the majority of unhandled errors
This is essential in order to handle asynchronous exceptions in Adobe's own code. I find the OLAPCube class extremely buggy and I need a way to intercept errors like the one below (it occurs at random about 5% of times, without any rhyme or reason).
TypeError: Error #1009: Cannot access a property or method of a null object reference. at mx.olap::OLAPCube/updateDimensions()[C:\Work\flex\dmv_automation\projects\datavisualisation\src\mx\olap\OLAPCube.as:552] at flash.utils::Timer/_timerDispatch() at flash.utils::Timer/tick() I'm not sure I understand the reason for the priority of this item still being "C"? I understand it may be a complex issue to solve and may take some time, but given that this issue has the highest number of votes (45% more than the next closest) and turns 2 years old in June, shouldn't it at least be prioritized accordingly? Otherwise, what is the point of having the public voting system?
I'm not trying to be critical, just trying to understand what is going on. Try already over 3 years old. See related Flex bug from 12/2005. http://bugs.adobe.com/jira/browse/SDK-9790
Glad to be in good company as I add another request for this, especially as it relates to ErrorEvents. I want to be able to write unit tests for my custom components that will fail if there is any sort of error. Since component methods such as "draw()" are executed asynchronously, any errors that happen as a result of that "draw()" call are dispatched as ErrorEvents. I have no way of setting up a global ErrorEvent handler on my component so my unit tests pass even though there is an error. Yes, I know that I get a dialog when an error happens, but I want to automate these unit tests and put them onto a continuous integration build server so that everytime a developer checks in code to source control the unit tests run automatically and fail the build if there is a unit test failure. This is pretty standard stuff for most development platforms, but I can't do it in Flash because of this limitation.
We all know that Flash Player itself has this capability, because it shows us those dialog boxes in the debug version! Can't you just expose that functionality to us in a programmatic way? Ideally, I would love to see something perhaps at the ApplicationDomain level (as someone previously suggested) that allowed for application-wide error handlers. Just adding my support to this request; it's quite astounding how much support it has, yet how old it is!! The ability to be able to trap exceptions thrown from separate threads, such as those caused by events, is a must.
I'd love love love to see this implemented...
Support for global error handling is so basic and fundamental to any framework or runtime. The fact that the player has gone this long without support for this is embarrassing. If Adobe wants to avoid losing ground to Silverlight they must support the basic needs of developers.
Hand-in-hand with this issue is the need to support full stacktrace reporting by the runtime player (rather than just debug player). https://bugs.adobe.com/jira/browse/FP-644 Someone from Adobe, please comment on this issue.
Is it too hard to develop ? Do you really think it deserves the lowest priority ? You can't ignore this. Or why have a voting system ? If this feature is too hard to implement, maybe some incremental steps can be taken. For example in SilverLight, a global exception hander is declared and managed at the plug-in level in Javascript. This is not the ideal solution, but if at least we had this in Flash we could start addressing some of the needs expressed here. Wow. I've got to say I'm amazed this is a feature request. I just took it as a given that this would simply exist.
I've used a lot of development tools over the years, and pretty much everything I've used in the last decade or so has some degree of global exception handling. But not ActionScript! You're kidding us right Adobe? I'm pretty careful when it comes to coding, and I do put in a lot of exception handling where it is warranted. For example, I need to capture errors when translating some XML returned from my server in case the server messes up and returns something other than XML. But every now and then I make a change that affects something else and an error occurs. Sometimes, I've even released a product with the odd bug still in it. Which is exactly why I always put global exception handling routines in place to log, and alert me to, any such problems. Are you really telling me I can't do this in ActionScript though? Really??? I don't think Adobe is reading this...
Otherwise the would have responded... This is a VERY easy feature as they already showing the error window, firing an event prior to that will probably take an Adobe developer 5 min to code. Someone needs to find a way to get the attention of Adobe as the bug base does not do the trick. Maybe on the Adobe forums as I think some of the Adobe devs do visit... We need it as well for our HUGE Flex application ( Free Digital Signage at http://www.MediaSignage.com ) Regards, Sean - MediaSignage.com Adding my vote! Adobe, this is a HUGE issue.
Unless you want Flash Player's reputation to change from the most ubiquitous browser plug-in to the most buggy one (for most users won't understand the difference between Flash Player being buggy or the application running on top of it), don't fix it. I have some applications out there that freeze every now and then in a customer's browser with no way to know about it, reproduce it and much less fix it. Regards, Sander Kruger www.3gsp.eu One way to get attention from adobe, please send a mail to the asignee of this feature request. Mr Justin Everett-Church. --> blog@justin.mailshell.com (This is the email he publishes in his blog)
I think he already gets all comments as the bug assignee :)
And being a product manager also complicates this issue. We can only try Adobe CEO/CIO addresses or even Bill Clinton's :) Dear all past and future commenters,
Can we remove the tone of populist rage from comments for this bug/feature request? By all means, let Adobe know that you want this feature, but making claims akin to the total downfall of the Flash Player without it and/or openly criticizing the development team for not having the foresight to put it in are not only absurd and unproductive, but are unlikely to accelerate this issue's resolution. Let's all remember that the Flash Player used to support a very loosely-typed scripting language for animation, and robust error handling was hardly a requirement for that. Sure, Adobe should have dealt with robust error handling when they went to AS3, but we've all got features that in hindsight we wish we put in to our software in prior releases; are we all total idiots for missing them? I absolutely agree that if developers (myself included) are going to take the Flash platform seriously over the long term, robust error handling is a prerequisite, but like all legacy platforms I'm sure there's lot more work involved in addressing and regression testing this change than the mere five minute's worth of work that some commenters assume it will be. Maxim I can't really agree. It's clear that the tone changed because nobody from Adobe reacts. How many issues have +250 votes? Is it so hard to keep us up to date on the status from time to time? We are 2 YEARS further and we haven't heard a thing about it. I once wrote that it would have been way better to fix all the nitty gritty details of Flex and create a product that really shines instead of coming with another product like Catalyst....
I agree with Tom Van dem Evnde, all Adobe has to do is just put it's status or reasoning out on why it's not being addressed or being addressed. I think everyone is trying to push for it so it gets included in the AS4 release, and that's where i am hoping it goes as well.
Thank you for all of the valuable feedback and comments on this issue. We have various request for this feature and are working to have this addressed. Rest assured, Adobe is reading this as well as other other features and is committed to delivering this in a future Flash Player release.
Maxim, there can be a "five minute's" solution (even in 10.x player version!), apart from subsequent sophisticated solutions:
Please add an "onerror" parameter to Flash Player parameters that can be assigned by a javascript function name. Any error is then passed to this function (only if "allowscriptaccess" is set to true, of course). Then, developer can pass the error object back to Flash via ExternalInterface. Simple, sufficient. Inspired by Silverlight. Must have for Flex, no doubt about it, so must have for FP.
One possible solution could be to make all the ErrorEvents set to bubbling = true by default, then we could at least intercept all error events we can think of by setting a listener to stage...
This and wrapping the application in a try-catch could be enough then, unless I've misunderstood something. We're using a version of that approach at the moment by using a listener for the "error" event on the Application tag and dispatching ErrorEvents through it. Unfortunately, this only works if the events are dispatched by a component in the display list, and I seem to remember that it has some issues in multi-module projects depending upon which ApplicationDomain the event was sent out from. We haven't tried the stage yet - that might work a little better.
Even so, this approach still doesn't help with unhandled Errors thrown anywhere in the app (either inside or outside of the display list), so that's the item we really need addressed. Another try to solve problem: http://100mbit.ru/?p=247
Use babelfish.yahoo.com for translate (but babelfish breaks actionscript sources) @Robert Sköld
The issue here is trapping unhandled exceptions that are thrown as a result of unhandled callbacks or null pointers and/or aren't thrown by objects in the display list. For example, you could wrap your entire application entry point in the try/catch statement, but it would only check that the lines in the try block execute correctly, and still wouldn't prevent unhandled exceptions being thrown by event code. I understand this issue is tricky, because some security warnings shouldn't be suppressed by the developer, but please can we not have @Pavel Šimek's solution... I'd rather go without than have that. Jodie, my solution is:
1) sufficent for AJAX application containing flash components. There is a top-level JavaScript code managing the whole application and all of its components. This code needs to know about errors occured in individual components. 2) temporarily sufficent even for pure Flash apps (using the External Interface to send errors back into SWF). I definitely agree that the final solution must be in ActionScript itself. But I anticipate it to be not so simple for Adobe. Whereas my solution is - we could have in the next minor release of Flash Player, IMHO. Pavel,
I understand that your proposal carries merit in across certain implementations; but there's also a huge assumption that most developers are integrating their apps into JavaScript applications in the DOM. There are loads of other use-cases where this wouldn't be the case - AIR being a huge one, but also apps that are distributed as self-contained widgets. There are a lot of people watching and commenting on this issue, and the solution would need to benefit the majority for it to be worth any effort. But if the ErrorEvents, by default would be bubbling, setting an addEventListener to the stage would handle all the "unhandles callbacks", but the problem would probably be null references, as the try-catch doesn't handle any of those really by wrapping the "app-initializer". I don't really see a problem with it, as long as the developer would be resending those error events to something like their own logger.
Would be awesome so a live website could use a service like getexceptional.com I just wanted to add my vote to this issue. I too migrated from the world of C# in order to try for the promise of building real desktop software using Adobe AIR. One of the first tasks I assigned a developer was "add a crash reporting system". We've had one in our C# product for 3.5 years, and I can't tell you how many times it has saved us. My developer pointed me to this bug, and I was shocked. From what I understand so far, my users will see no indication that anything is wrong, other than whatever side effects the unhandled error happens to cause. So, let me add my voice the chorus: Please fix this issue for us.
Agree with everyone. This is not just a feature request, this is a REQUIREMENT for enterprise-class AS3-based applications. I've a huge one right now live that we're trying to track down intermittent issues on that are throwing exceptions. Adobe may/may not be worried about Silverlight catching up, but they should be. Silverlight already has enterprise-level features like this, right now! We need them, too!
I agree with all the other comments. Without this, anybody trying to build a true enterprise application is at great risk. This issue cannot possibly be allowed to remain at a priority of C.
If you want Flex just to be a cute platform for some really good promotional animations, then it is a C, but if you are touting Flex as an enterprise platform it is an A+. I guess the response to this bug will tell us what Adobe thinks AIR/Flex/Flash is suitable for. And still, Adobe ignores this issue.
I heard there's a new thing called Silverlight, I wonder if it can catch global exceptions... No, really, if you want the developers to take Flex seriously - you have to do something about us. When we develop an application that we intent to sell for millions of dollars, and exception on screen is a big no no! Pretty sure Panorama and Cognos both have implmentations of this in there enterprise apps, I've seen demos of Cognos and they look pretty nice, Panorma i think only has their dashboard up and now maybe their analytical tool, they have to be using something for error catching in their apps.
Nice...you should have seen the face of the java developers I work with when I told them about this. Even crappy php has this.
Related ticket from frustrated Flex developers: FP-1499
I can't believe this ticket is almost 2 years old (next week). Come on Adobe! The debug player obviously has this capability as we get the error popups with that. I'd just like to point out that, while a possible workaround is having your customers install the debug version of the Flash Player, this isn't a possibility with AIR... Their application just starts behaving weirdly after some hidden unknown exception occurs. It would actually be better if an exception would just cause the app to crash.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Feature Request
Under Investigation
C
Ability to intercept system error dialogs
The try catch is a reasonable workaround, but it fails when the the catch happens in a different frame from the try, or when there's an error in the code that couldn't be caught at compile time (such as a null pointer).
This issue has been visited before. Passing this along for a fresh look.