bserdar
commented
9 years ago i agree that the definition is not adequate, and needs to be revised.
The crucial points are:
- Context is parsable by the client. Stack trace is not.
- Context includes data, stack trace does not.
Stack trace is valuable to the developers, so logging the stack trace is useful.
Stack trace is not valuable to a client app. Error codes and error context information is much more usable. Client can use the error code and context information in Error object to display error information that actually means something to the end user.
On Mon, Jan 19, 2015 at 1:43 PM, Dennis Crissman notifications@github.com wrote:
Exert from user doc:
context: A string delimited with "/" characters that define the context of execution where the error occurred, similar to a stack trace.
This definition leaves me struggling to understand what the context is intended to be. I don't know if it is the recursive use of the word "context" or the comparison to a stacktrace, but regardless, I don't think the definition clearly encapsulates the concept that the context is intended to represent.
For example, why would a context trace be preferred over a stacktrace for a server side error? Or maybe better, what can the context provide that could not be included in an Exception's message? A stracktrace does an excellent job showing where in the code something broke, why duplicate that? That said, a stacktrace does not give any indication of the conditions that caused the exception to be thrown (again, possibly outside of the Exception's message), which is where I think the context does a better job.
I think if we had a clear definition of "context" we could begin to look at the code and ask if various uses of context and/or exceptions are appropriate, or would the other be better?
— Reply to this email directly or view it on GitHub https://github.com/lightblue-platform/lightblue-docs-user/issues/63.
dcrissman
Exert from user doc:
This definition leaves me struggling to understand what the context is intended to be. I don't know if it is the recursive use of the word "context" or the comparison to a stacktrace, but regardless, I don't think the definition clearly encapsulates the concept that the context is intended to represent.
For example, why would a context trace be preferred over a stacktrace for a server side error? Or maybe better, what can the context provide that could not be included in an Exception's message? A stracktrace does an excellent job showing where in the code something broke, why duplicate that? That said, a stacktrace does not give any indication of the conditions that caused the exception to be thrown (again, possibly outside of the Exception's message), which is where I think the context does a better job.
I think if we had a clear definition of "context" we could begin to look at the code and ask if various uses of context and/or exceptions are appropriate, or would the other be better?