[dart-misc] Framework strategy for "wrapping" an exception?

[Matan Lurey]

AngularDart currently has the concept of a *WrappedException
<https://github.com/dart-lang/angular2/blob/master/lib/src/facade/exceptions.dart#L18>.*

Basically, it's a framework-level *Exception* that wraps another; we use it
for example to capture an exception that occurs in user-code but expose why
the exception was caused where it was caused, for example,
*ViewWrappedException
<https://github.com/dart-lang/angular2/blob/2f5ba45a83ecd29ab2ee407890c2e03cd3c2e59e/lib/src/core/linker/exceptions.dart#L46>*
.

Basically, there is code like

try {
runUserCode();
} catch (e, s) {
throw new WrappedException(e, s, context: 'View instantiation');
}

Is there a better strategy for doing this or any known libraries or
patterns for this type of error/exception encapsulation?

~ Matan

['Paul Berry' via Dart Misc]

We had a discussion about this on dart-analysis-team a few months ago:
https://groups.google.com/a/google.com/forum/#!search/dart-analysis-eng$20use$20error.stackTrace/dart-analysis-team/dbzUtefrm3s

TL/DR: we have a similar pattern in analyzer; we don't all agree that it's
a good pattern, and there were some ideas for improving it, but we didn't
reach enough of a consensus to make any changes.

Still, it might be useful background reading :)

Post by Matan Lurey
AngularDart currently has the concept of a *WrappedException
<https://github.com/dart-lang/angular2/blob/master/lib/src/facade/exceptions.dart#L18>.*
Basically, it's a framework-level *Exception* that wraps another; we use
it for example to capture an exception that occurs in user-code but expose
why the exception was caused where it was caused, for example, *ViewWrappedException
<https://github.com/dart-lang/angular2/blob/2f5ba45a83ecd29ab2ee407890c2e03cd3c2e59e/lib/src/core/linker/exceptions.dart#L46>*
.
Basically, there is code like
try {
runUserCode();
} catch (e, s) {
throw new WrappedException(e, s, context: 'View instantiation');
}
Is there a better strategy for doing this or any known libraries or
patterns for this type of error/exception encapsulation?
~ Matan
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Harry Terkelsen' via Dart Misc]

In dart2js we have to handle errors in user code since users must supply
their own functions to read the contents of URIs. Instead of creating a
wrapped exception, however, we have another method in our logger called
`crashInUserCode` that takes the exception, stack trace, and a message
(usually along the lines of "Uncaught exception in input provider"). When
we catch an error in user code, we report it with the `crashInUserCode`
logger function and then rethrow the original exception.

To be honest, I'm not partial to one way or the other.

On Fri, Jan 27, 2017 at 5:39 AM 'Paul Berry' via Dart Misc <

Post by 'Paul Berry' via Dart Misc
https://groups.google.com/a/google.com/forum/#!search/dart-analysis-eng$20use$20error.stackTrace/dart-analysis-team/dbzUtefrm3s
TL/DR: we have a similar pattern in analyzer; we don't all agree that it's
a good pattern, and there were some ideas for improving it, but we didn't
reach enough of a consensus to make any changes.
Still, it might be useful background reading :)
AngularDart currently has the concept of a *WrappedException
<https://github.com/dart-lang/angular2/blob/master/lib/src/facade/exceptions.dart#L18>.*
Basically, it's a framework-level *Exception* that wraps another; we use
it for example to capture an exception that occurs in user-code but expose
why the exception was caused where it was caused, for example, *ViewWrappedException
<https://github.com/dart-lang/angular2/blob/2f5ba45a83ecd29ab2ee407890c2e03cd3c2e59e/lib/src/core/linker/exceptions.dart#L46>*
.
Basically, there is code like
try {
runUserCode();
} catch (e, s) {
throw new WrappedException(e, s, context: 'View instantiation');
}
Is there a better strategy for doing this or any known libraries or
patterns for this type of error/exception encapsulation?
~ Matan
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Matan Lurey]

Thanks, these were both useful to me. I guess it makes sense to keep
*WrappedException* for now.

~ Matan

On Fri, Jan 27, 2017 at 9:35 AM 'Harry Terkelsen' via Dart Misc <

Post by 'Harry Terkelsen' via Dart Misc
In dart2js we have to handle errors in user code since users must supply
their own functions to read the contents of URIs. Instead of creating a
wrapped exception, however, we have another method in our logger called
`crashInUserCode` that takes the exception, stack trace, and a message
(usually along the lines of "Uncaught exception in input provider"). When
we catch an error in user code, we report it with the `crashInUserCode`
logger function and then rethrow the original exception.
To be honest, I'm not partial to one way or the other.
On Fri, Jan 27, 2017 at 5:39 AM 'Paul Berry' via Dart Misc <
https://groups.google.com/a/google.com/forum/#!search/dart-analysis-eng$20use$20error.stackTrace/dart-analysis-team/dbzUtefrm3s
TL/DR: we have a similar pattern in analyzer; we don't all agree that it's
a good pattern, and there were some ideas for improving it, but we didn't
reach enough of a consensus to make any changes.
Still, it might be useful background reading :)
AngularDart currently has the concept of a *WrappedException
<https://github.com/dart-lang/angular2/blob/master/lib/src/facade/exceptions.dart#L18>.*
Basically, it's a framework-level *Exception* that wraps another; we use
it for example to capture an exception that occurs in user-code but expose
why the exception was caused where it was caused, for example, *ViewWrappedException
<https://github.com/dart-lang/angular2/blob/2f5ba45a83ecd29ab2ee407890c2e03cd3c2e59e/lib/src/core/linker/exceptions.dart#L46>*
.
Basically, there is code like
try {
runUserCode();
} catch (e, s) {
throw new WrappedException(e, s, context: 'View instantiation');
}
Is there a better strategy for doing this or any known libraries or
patterns for this type of error/exception encapsulation?
~ Matan
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an