More verbose error messages within promises #127

Closed
kylehotchkiss opened this Issue Feb 13, 2015 · 8 comments

Comments

Projects
None yet
3 participants
@kylehotchkiss

http://f.cl.ly/items/3p1K0e2e060I1R2V1o0l/Image%202015-02-13%20at%201.36.59%20PM.png

This may be more of a question for upstream promises library, but is there anyway to get a more informative stack trace within errors? (file names/line numbers for the error that promice value is referring to). I have my app inside of a marty .when() to make sure a user is logged in (this may be an antipattern but I'm not really sure of a better way to handle in flux) so pretty much every error I experience is now routed into the promises and it's a bit tricky to debug

(the error at play is actually in a flux source file, the reference to user may look it like it's an issue with the flux setup but that this.state.user.when actually works fine, just introduced an error later on as an example)

@jhollingworth

This comment has been minimized.

Show comment
Hide comment
@jhollingworth

jhollingworth Feb 13, 2015

Contributor

You're not alone on this one, I've been getting feedback from various people that debugging issues can be a pain.

Problem is promises are kind of designed for catching errors and rejecting them... If I added some logging around store action handlers and StateMixin#getState giving some context will that help things?

Contributor

jhollingworth commented Feb 13, 2015

You're not alone on this one, I've been getting feedback from various people that debugging issues can be a pain.

Problem is promises are kind of designed for catching errors and rejecting them... If I added some logging around store action handlers and StateMixin#getState giving some context will that help things?

@kylehotchkiss

This comment has been minimized.

Show comment
Hide comment
@kylehotchkiss

kylehotchkiss Feb 13, 2015

That sounds great to me!

I eventually found that if I dig into the promise itself, a parameter called "stack" had some clues to where to find errors. It's originally hidden and needs to be clicked on to expand. If the filename/line number inside of that stack could be pulled all the way up to the top level error thrown by promise somehow, that would be nice as well.

!(http://f.cl.ly/items/05100B1X0E2d1E0D3f20/Image%202015-02-13%20at%204.47.26%20PM.png)[http://f.cl.ly/items/05100B1X0E2d1E0D3f20/Image%202015-02-13%20at%204.47.26%20PM.png]

That sounds great to me!

I eventually found that if I dig into the promise itself, a parameter called "stack" had some clues to where to find errors. It's originally hidden and needs to be clicked on to expand. If the filename/line number inside of that stack could be pulled all the way up to the top level error thrown by promise somehow, that would be nice as well.

!(http://f.cl.ly/items/05100B1X0E2d1E0D3f20/Image%202015-02-13%20at%204.47.26%20PM.png)[http://f.cl.ly/items/05100B1X0E2d1E0D3f20/Image%202015-02-13%20at%204.47.26%20PM.png]

@jhollingworth

This comment has been minimized.

Show comment
Hide comment
@jhollingworth

jhollingworth Feb 13, 2015

Contributor

Ah nice, hadn't seen that before!

I will look into this over the weekend and try and improve the debugging story

Contributor

jhollingworth commented Feb 13, 2015

Ah nice, hadn't seen that before!

I will look into this over the weekend and try and improve the debugging story

@kylehotchkiss

This comment has been minimized.

Show comment
Hide comment
@kylehotchkiss

kylehotchkiss Feb 13, 2015

thanks so much james, appreciate your help

thanks so much james, appreciate your help

@engineersamuel

This comment has been minimized.

Show comment
Hide comment
@engineersamuel

engineersamuel Feb 13, 2015

I might also suggest a look at https://github.com/kriskowal/q + setting Q.longStackSupport = true. I actually am wrapping the ajax call in a Q promise in my *API and it is working very well.

I might also suggest a look at https://github.com/kriskowal/q + setting Q.longStackSupport = true. I actually am wrapping the ajax call in a Q promise in my *API and it is working very well.

jhollingworth added a commit that referenced this issue Feb 14, 2015

Improve error logging
People have been finding it hard to diagnose where errors come from
because the promises would swallow them. I've added some logging around
places where Marty calls into user code, namely:

- Store#handleAction: We log the store, action handler, error and action
- StateMixin#getState: We log the view and error
- when: We log the fetch, store and error
- ActionCreator: We log the action type, action, action creator and error

Resolves #127
@jhollingworth

This comment has been minimized.

Show comment
Hide comment
@jhollingworth

jhollingworth Feb 14, 2015

Contributor

Marty v0.8.12 should have improved logging for exceptions. Let me if that helps or not

Contributor

jhollingworth commented Feb 14, 2015

Marty v0.8.12 should have improved logging for exceptions. Let me if that helps or not

@kylehotchkiss

This comment has been minimized.

Show comment
Hide comment
@kylehotchkiss

kylehotchkiss Feb 17, 2015

Yes! it is easier to debug now. Thanks for your help!

Yes! it is easier to debug now. Thanks for your help!

@jhollingworth

This comment has been minimized.

Show comment
Hide comment
@jhollingworth

jhollingworth Feb 17, 2015

Contributor

👍

Contributor

jhollingworth commented Feb 17, 2015

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment