Rethrow a new Exception preserving the cause

[Gonzalo Chumillas]

I would like to rethrow a new exception preserving the original exception. For example

try {
   buggyFunction();
} catch (exception) {
   throw new MyCustomException(exception);
}

This way I can provide more specific information, without losing the original exception (the cause). In the same way that this guy explains:

http://programmers.stackexchange.com/a/278038/173231

Is that possible?

Thanks.

[Kasper Lund]

Looks like this might be answered by:

http://stackoverflow.com/questions/16028565/how-do-i-rethrow-an-exception-and-preserve-the-stack-trace

Cheers,

Kasper

--
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 email to misc+uns...@dartlang.org.

[Günter Zöchbauer]

try {
   buggyFunction();
} catch (exception) {
   rethrow;

[Gonzalo Chumillas]

Thanks. In my case I don't want to rethrow the same exception. I would like to throw a new custom exception and, at the same time, preserving the cause (the original exception).

But I think Dart doesn't consider this circumstance, sadly.

[Gonzalo Chumillas]

Thanks Günter. In my case I don't want to rethrow the same exception. I would like to throw a new custom exception and preserve the previous exception (the cause). Doing something like that is possible in other languages, such as PHP:

http://programmers.stackexchange.com/a/278038/173231

[Lasse R.H. Nielsen]

On Tue, Aug 9, 2016 at 8:08 PM, Gonzalo Chumillas <gonzalo....@gmail.com> wrote:

Thanks Günter. In my case I don't want to rethrow the same exception. I would like to throw a new custom exception and preserve the previous exception (the cause). Doing something like that is possible in other languages, such as PHP:

http://programmers.stackexchange.com/a/278038/173231

Dart Errors don't have a `cause` field. Errors generally don't have a different cause, they are "stand-alone" error reports and are not expected to be intercepted at all, except at a framework level. 

Exceptions (any non-error object thrown) represents communication with the calling code, and it should include exactly the information expected by the caller. There are no general guide-lines for exceptions any more than there are general guide-lines for any returned object.

If you make an exception, e.g., thrown from an API layer, that can report multiple ways something specific could fail, you can add a `cause` field to that exception - if you think the caller can use that information for anything.

/L

--

Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[tatumizer-v0.2]

Quite often, you need to add some context info to exception object on its way up. 

There's no way to do it in java either: it's not a new exception CAUSED BY low-level exception; it's the same low-level exception with added context info.

We discussed it a couple of years ago here, but it ended in nothing. 

It's possible to implement simple mechanism in java that doesn't even require intercepting exception.  But in dart, because to async calls, you can't rely on stack, so  probably an "attachment" hook is needed in exception object. Or maybe this is the use case for expando? (which is currently way too slow for anything). 

Not sure. @Lasse: your response doesn't seem to address this feature.

[Lasse R.H. Nielsen]

No, I was just addressing using a `MyCustomException` to include the cause.

If you want to add more information to an existing error, you need to either create a new error of the same type with more information or attach the information on the side of the object. You can do that using an Expando, but if you know that the exception will be caught shortly after and the extra information consumed there, you can also just use an identity map and remove the entry again at the catch point.

/L

[tatumizer-v0.2]

It should be a weak map. Not sure dart has weak maps per se, but expando provides a kind of rough equivalent (based on its description from dartdoc)

 

[tatumizer-v0.2]

Maybe exception object should have an attached map of names/values.

But this doesn't fully solve the problem.

Writing

var myAttachmentObject=...

try {

   ...

} catch (ex) {

   ex.addAttachment("foo", myAttachmentObject);

   rethrow;

}

is very tedious. And the case is quite common to justify supporting it in a language specifically.

[ Notice that myAttachmentObject has to be declared outside of try{} block - disgusting! ]

Ideally, there can be and operator like (better name to be found) on-exception-call-this-function((e)=>doSomething) which doesn't really catch an exception, just calls a function during unwinding a stack.

This operator should work in a scope of a block. (Exit from block will remove it from stack).

Not sure why this feature is not supported by any language. Probably, mundane stuff like that is too lowly for language designers.

 

.

[tatumizer-v0.2]

Much simpler idea: there should be a way to add information to stack trace. Not sure how it can look syntactically, and what to do with asynchronous calls, which create an amorphous mess in runtime (async/await hack making it even worse).

The whole idea of Circuit (if anyone remembers this promising concept, by now defunct) was to create a structure to sort out the mess. Sadly, the idea was not appreciated by contemporaries :(  

Does Fuchsia have a message board? These people seem to be more susceptible to innovative ideas.

[tatumizer-v0.2]

More specifically: would it be possible to add a new field (e.g., "attachment" or something) to stack_trace.Frame?

So that we can call stack_trace.currentFrame.addAttachment(name, value)

(because Frame can refer to async "stack frame", then there's no difference in API between async stack and normal stack).

There's no removeAttachment. Attachment records will be (naturally) cleaned up when frame goes out of existence.

When stack trace is printed, attachments are printed automatically.

I think it's a cool feature, really. It will eliminate a lot of nonsense like catching exception just to add stuff to it (java added special mechanism of suppressed exceptions in 1.7 for that purpose, but it's ugly anyway: you still have to catch and re-throw).

 

 

  

[Lasse R.H. Nielsen]

On Wed, Aug 17, 2016 at 5:43 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

More specifically: would it be possible to add a new field (e.g., "attachment" or something) to stack_trace.Frame?

So that we can call stack_trace.currentFrame.addAttachment(name, value)

(because Frame can refer to async "stack frame", then there's no difference in API between async stack and normal stack).

There's no removeAttachment. Attachment records will be (naturally) cleaned up when frame goes out of existence.

You can suggest that to the stack_frame package. It won't work if you don't use that package (the language doesn't represent individual stack frames in any way, the only primitive is the full StackTrace object).

Which likely also means that it isn't possible to attach anything to the "current stack frame" in practice. The Frame of the stack_trace package is created after the fact by parsing the stack trace string.

 

When stack trace is printed, attachments are printed automatically.

I think it's a cool feature, really. It will eliminate a lot of nonsense like catching exception just to add stuff to it (java added special mechanism of suppressed exceptions in 1.7 for that purpose, but it's ugly anyway: you still have to catch and re-throw).

/L

--

Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

--

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 email to misc+uns...@dartlang.org.

[Bob Nystrom]

+Natalie, who is the maintainer of the package in question. :)

– bob

[tatumizer-v0.2]

I know it's not easy to implement. But the good news is: all "conceptual" building blocks are already there, so it's easy to express this in the form "add attachment to stack frame", and it will look as if it's a simple operation. Sure, if you don't use the stack_trace package, it won't work - but that's fine (no stack trace - no attachments obviously)

[tatumizer-v0.2]

As an aside: I can't imagine any production system which deliberately avoids stack_trace package. You get an exception from deeply nested async - and you don't even know how program got there, and you don't have any clues (even from the log) that link said error with its possible cause.

[Alex Tatumizer]

Prior art: http://blog.honeybadger.io/how-to-add-context-data-to-exceptions-in-ruby/

They use different terminology. In dart's case, it would be equivalent to stack_trace.addContext(dict) or something