--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
I feel like I'm chaining correctly and putting in a lot of onError and whenComplete etc but I still run into "unhandled exceptions".
Are there good patterns for this?
You can give async:runZonedExperimental a try. It should catch all uncaught errors except the ones from isolates and the DOM.See tests/lib/async/catch_errors.dart for an example on how to use it.caveat: as the name suggests. This is still experimental.On Thu, Jun 27, 2013 at 7:03 PM, Seth Ladd <seth...@google.com> wrote:
Hi server-side Dart developers and library authors,I'm writing a lot of server-side Dart code these days, and I keep running into exceptions that crash my server because they are unhandled. What is a good pattern to follow so that I ensure all exceptions are handled and don't take down the running process?There's a LOT of async code going on (HTTP server, Postgress, Google+ API, and more). I feel like I'm chaining correctly and putting in a lot of onError and whenComplete etc but I still run into "unhandled exceptions". Even if I do an awesome job (or maybe I'm doing a really poor job?) of putting in all the error handlers, I still use a lot of code that I didn't write which may throw exceptions from deep within async chains.What I'm looking for is:1) A global, for-real way to handle all unhandled exceptions. So nothing slips through and takes down the server.
2) A way to get the full stack trace of where the exceptions originally occurred (no matter how asyncy), so I can do something about it.
I see two APIs that might help me, but marked as Experimental: runZonedExperimental and getAttachedStackTrace. So I feel like it's a know problem, but one we don't have a solution for (yet)
----Are there good patterns for this? What have others done?Thanks!Seth
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett
On Thu, Jun 27, 2013 at 10:03 AM, Seth Ladd <seth...@google.com> wrote:
I feel like I'm chaining correctly and putting in a lot of onError and whenComplete etc but I still run into "unhandled exceptions".Are you using onError, or catchError()? My understanding is that you almost always want the latter.
Are there good patterns for this?For pub, our basic rules are:
- Avoid asynchrony whenever possible. The maintenance overhead is rarely worth the performance (for us).
- Any method which internally uses a Future must return a Future, and all async errors must be piped to that future.
- If a method returns a Future, all runtime errors must be reported through that and not thrown synchronously.
- Write a giant pile of tests. Test all of your failure modes.
- Cry and be sad once you start dealing with Streams too.
It's certainly not been easy for us but pub is relatively good at not top-leveling errors at this point. It has an easier job because it doesn't stay running for very long, though.Cheers,- bob
--
shouldn't have answered while rushing out of the office. You had already discovered `runZonedExperimental`...
>> For instance, if I remove the return from renderJsonObject and that method fails nobody will catch the error and it will crash the server.
I think this is normal behavior in this case.This is due the fact the inner future not attached to outer future.Outer future are method body of "handle" and inner future are call to "renderJsonObject".Exceptions propagated only through continuations (chains).This type of exception handling may be not supported in Dart.This is default behavior in Microsoft NET (all task detached from parents).But in Microsoft NET this is not a problem because they proposed new way of async writing code with "await".Awaitable not required continuations. It trap exceptions similar to synchronous.You can writetry {await SomeExceptionalTask();print("Hello");} catch(e) {}This code will generated to state machine. State machine not required continuations.It works as executor of synchronous code blocks. Only states switched asynchronously.But Dart work not as state machine.But as I understand from your words outer future ignore exceptions in inner future.This not works in current Dart implemetation.void test() {new Future(() {new Future(() => throw null);}).catchError((e) {print(e); // Never called} );}I often say that Dart futures are obsolete.But Dart continue improving obsolete technology.This not means lack of "await".Not. This is lack effective cooperative-parallelism.You cannot run future in parallel effective even in cooperative mode.This is not supported in Dart.
void test() {new Future(() {new Future(() => throw null);new Future(() => throw null);new Future(() => throw null);}).catchError((e) {print(e);} );}Alos you cannot simple to cancel the jobs running in cooperative-parallel way.This words not helps to something. This is just attention.
>> If the inner Future (the one that throws null) could be automagically wired to the outer by the "compiler" it would save a lot of headaches.
Often this done not "automagically by compiler".This often done in programmatic way by your own wish.
>> I think (correct me if I'm wrong) that what you are trying to do here can be effectively achieved with one of the static functions found in Future:
>> static Future<List> wait(Iterable<Future> futures)
Not. If you you forgotten to add return here then the exceptions becomes unhandled.It just wait when all completed but not attached to outer future.And you are sure that they are run in a cooperative-parallelism mode but not in sequence mode?void test() {new Future(() {Future.wait([new Future(() => throw null),
new Future(() => throw null)
]);
}).catchError((e) {print(e); // Never called} );}
Also exists another way to solve this problems. But is also required some style of programming and supplied libraries.
It allows to simulate the state machine (or similar) but code are written in human way.This is not a "then hell" but...... I don't want to say now but I am trying to write supplied library that will be allow write async code similar to synchronous (with some approximation).This idea half from my head and half from "Typescript Promise await" proposal.This is not the same as "Typescript Promise await" proposal but similar.The same idea but different implementation and usage.If I have the time and desire I'll write it.If you want to know about what I say please look at "Typescript Promise await" library and guess yourself.
try { breedMoreLlamas(); } on OutOfLlamasException { // A specific exception buyMoreLlamas(); } on Exception catch(e) { // Anything else that is an exception print('Unknown exception: $e'); } catch(e) { // No specified type, handles all print('Something really unknown: $e'); }...but in practice this is too heavy.
How would you annotate a function that can throw a sync exception and return an async error (I know this is not a good practice, but it is in fact, possible)? Something like:Future<String> badPractice() throws Exceptionwould mean it can sync throw Exception, but how would you specify that it can throw Exception async too?
Is Google developed Dart only for Dart Team or it developed it for world-wide community?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
This Zone thing - I'm surprised in didn't make headlines in the mailing list. I expected BREAKING NEWS or something, but it never materialized.Strange - because it's a BIG DEAL.Maybe it is not 100% figured out yet, but definitely, it's a good step toward disentangling current mess of error processing in async runtime.
I just wanted to say: I appreciate it.Is it really difficult to intercept DOM callbacks to cover all bases?
One of the consequences:, the effect won't be limited to dart VM - code generated by dart2js would enable sane error processing in browsers, which is currently completely missing.I also lilke the fact that Zone is a self-contained "small" concept. If any monadic mechanism ever emerges, it would be much simpler to implement on top of Zones.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
>> Is Google developed Dart only for Dart Team or it developed it for world-wide community?>> This must be a rhetorical question.>> Regarding api design, etc....>> Dart took the Future pattern from Java. Streams appear in Java concurrent programming also so that may be a borrowed idea as well, although the term "stream" is fairly generic and seems to appear in all sorts of different environments. Both no doubt are used identically elsewhere also.
This question is not about that what already implemented (but also include this).This question about how goes this process and which results of thereof (also including productivity of Dart Team).Breaking changes are the consequences of bad designing.Breaking changes take a time for refactoring.Conceptually Dart developed for community.The community consists not only of the boys from the village.They also programmers (often Java and C#).But Dart in many cases goes as follows.- Ignore community- Make work as its own wishCurrently I am saying about Dart SDK written in Dart language.There is no discussion about that:- Why this done in this way but not in another- Why you not ask community about how this would better implementOr you want to say that Dart SDK infrastucture organized as the best project in the world?Think about Synfony 1.X and Synfony 2.X.Think about Zend Framework infrastucture.In many case Dart SDK ideas goes from Java.But Dart SDK organized not as Java SE.Dart SDK organized sometimes as Synfony 1.X and sometimes as I cannot find similar analogy (plain PHP small framework?).All internal implementation in Dart SDK are used private interfaces.But at the same time, these interfaces describe the well-known technologies.Why this private implementation based on private (well-known) interfaces?Why this interfaces not public for best practice and re-use in Dart?This is bad design.This is closed to itself Dart SDK.Dart SDK not ready for using as basis for future enhancement and alternative implementations.This make Dart SDK are less universal becuase enhancement and alternatives not supported within this project infrastructure.Rhetorical question in this case.Who can implement this functionality for using with Dart SDK?Only Dart Team! No alternatives, re-using or enhancement allowed.Only Dart Team know forever which is the best way of using this product!
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
>> Mezoni's first example code is misleading,
I agree with you. Just tested (mix of sync and async actions). No difference.
>> Fwiw: we only expose a small sub-part of the zones-work so far (and even that is marked as experimental). Once the other core-libraries stabilize I want to spend more time on it.
Florian, good work.But why zones? Why not- UnitOfWork- WorkItem- AsyncWork- AsyncContext- TimeShare- Batch- Work- TimeCycle- TimeSlice- TimeSpan- TimeSlot- Timetable- Schedule- AsyncFlow- Flow- TimeFlow- TimeAction- Force- Extent
And why _Zone interface private?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
--
It can be protected at the container, like we did In Rikulo Stream. By assuming all handlers being asynchronous, one can catch all exceptions (except compile errors) at the container (or the very first general handler) and then forward the error, if any, into a (Java-like) general error handling mechanism, such as Stream's error handling.
On Friday, June 28, 2013 1:03:03 AM UTC+8, Seth Ladd wrote:Hi server-side Dart developers and library authors,I'm writing a lot of server-side Dart code these days, and I keep running into exceptions that crash my server because they are unhandled. What is a good pattern to follow so that I ensure all exceptions are handled and don't take down the running process?There's a LOT of async code going on (HTTP server, Postgress, Google+ API, and more). I feel like I'm chaining correctly and putting in a lot of onError and whenComplete etc but I still run into "unhandled exceptions". Even if I do an awesome job (or maybe I'm doing a really poor job?) of putting in all the error handlers, I still use a lot of code that I didn't write which may throw exceptions from deep within async chains.What I'm looking for is:1) A global, for-real way to handle all unhandled exceptions. So nothing slips through and takes down the server.2) A way to get the full stack trace of where the exceptions originally occurred (no matter how asyncy), so I can do something about it.I see two APIs that might help me, but marked as Experimental: runZonedExperimental and getAttachedStackTrace. So I feel like it's a know problem, but one we don't have a solution for (yet)Are there good patterns for this? What have others done?Thanks!Seth
> +1 I'm using rikulo stream for one of my server and I sometimes forget to catch certain errors but I'm protected by the framework.
I'm using it too, but that is only true if you don't fail to pipe all Futures which is, to say the least, difficult.We definitely need something in the language to handle uncatched errors. Specially those that are inside 3rd party libs you cannot modify. Something like a global try/catch but for async code.As far as I have understood that is supposed to be provided by Zone's. Am I right? I mean: will we be able to catch errors from unpiped futures using a zone in an arbitrary place of the application code or is it for anything different? I have had no time to look at them yet :-(...
> (or if we missed another asynchronous primitive). If we missed a place we would like to know.
And in the server? The same?
Ok.
My question was regarding the "forgotten async primitives" (whatever they are ;-)). I was assuming these are different in client and server.
For instance it looks like dart:io may have its own async primitives and it only works in server. But never mind I was just supposing things...
I will give the zones a try and if I see something strange will let the list know.
Thx.
Ok.
My question was regarding the "forgotten async primitives" (whatever they are ;-)). I was assuming these are different in client and server.
For instance it looks like dart:io may have its own async primitives and it only works in server. But never mind I was just supposing things...
I will give the zones a try and if I see something strange will let the list know.
Hi again:Tried to run the following code:<<<<void main() {
runZonedExperimental( () {
Socket.connect("localhost", 44444).then( (Socket s) {
print("_socket_: $s");
});
}, onError: (err) => print("_ops_: $err"), onDone: () => print("_done_") );}>>>>and nothing is caught by the zone. I get this in the console:<<<<Uncaught Error: SocketException: Connection failedUnhandled exception:
SocketException: Connection failed
#0 _DefaultZone.handleUncaughtError.<anonymous closure> (dart:async/zone.dart:148:7)
#1 _asyncRunCallback._asyncRunCallback (dart:async/event_loop.dart:9:15)
#2 _asyncRunCallback._asyncRunCallback (dart:async/event_loop.dart:13:7)
#3 _createTimer.<anonymous closure> (dart:async-patch/timer_patch.dart:8:13)
#4 _Timer._createTimerHandler._handleTimeout (timer_impl.dart:91:28)
#5 _Timer._createTimerHandler._handleTimeout (timer_impl.dart:99:7)
#6 _Timer._createTimerHandler.<anonymous closure> (timer_impl.dart:107:23)
#7 _ReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:81:92)
>>>>Am I doing something wrong? Or is it a forgotten primitive ;-)?
BTW: Would it make sense to return a Future from runZonedExperimental() instead of passing two parameters, onError and onDone?That way syntax would be prettier. Only that I'm not sure if it can be done because the returned Future could be chained and/or combined with other standard Futures and maybe that would interfere with the zonification.
A Stream instead of a Future? :-oDoes that mean that we can get more than one error from a zone?
@Florian: how do you think, won't it be a good idea to "cut all links" after a single error in the zone: just NOT CALL any "then" handlers after other futures complete? (So the zone essentially disintegrates)
(This is not necessarily related to the question at hand though).
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
If error occurs, situation may become so flaky and unpredictable that your "release" future will be never called anyway. Some Zone-wide mechanism of "finally" is needed: instead of "then" another handler should be called, no?
(Missing concept :-)
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new