Messages from Javascript missing exception.type and .message

[mpkorstanje]

@davidjgoss what is the stacktrace field supposed to be? I think that between Java and Javascript we have a discrepancy. In Java the stacktrace is a string representation of the entire exception. It is formatted as:

<exception type>: <exception message>
<exception stacktrace line 1>
<exception stacktrace line 2>

Supressed exceptions:
<supressed exception 1>

<supressed exception 2>

In Javascript it seems the exception is only the stacktrace lines of the direct trace of the exception? I.e:

<exception stacktrace line 1>
<exception stacktrace line 2>

As a result the pretty formatter renders the Java stacktraces with sufficient detail. But the JS ones miss the exception.type and .message.

Note: This showed up after cucumber/pretty-formatter#11 and probably relates to #302.

[davidjgoss]

In JavaScript it's implemented as:

• TestStepResult
  • message - everything - type, message and stack trace
  • exception
    • type - just type
    • message - just message
    • stackTrace - just the stack frames

The nested cause(s) are not currently represented at all.

Do you have a strong opinion on what's correct?

(I think react-components also has the JavaScript assumptions built in.)

[mpkorstanje]

message - everything - type, message and stack trace

Ah. In cucumber-jvm that is just the message.

And in the CCK, the type isn't included.

{
  "duration": {
    "nanos": 1000000,
    "seconds": 0
  },
  "exception": {
    "message": "BOOM",
    "stackTrace": "samples/stack-traces/stack-traces.feature:10",
    "type": "Error"
  },
  "message": "BOOM\nsamples/stack-traces/stack-traces.feature:10",
  "status": "FAILED"
}

I think it makes most sense to

• Fix cucumber-jvm to include the entire stacktrace.
• Update the documentation in messages to reflect the above
• Fix the CCK to include the type.
• Update pretty-formatter, {junit,testng}-xml-formatter and cucumber-json-formatter.

[davidjgoss]

Update the documentation in messages to reflect the above

Done in #315

Fix the CCK to include the type.

Done in cucumber/compatibility-kit@01d1b66#diff-01b3acf30947d9ed57ad58af17e2826c38f0ab8d7a1cb2374033233db115a894 as part of the rework of CCK devkit

[mpkorstanje]

With #302 in mind we have to give this some more thought.

[mpkorstanje]

@clrudolphi what is included in the .Net stacktrace?

[gasparnagy]

@mpkorstanje I think you wanted to quote @clrudolphi.

.NET is similar to Java I think. We have:

• exception.ToString() that is the full representation of the exception: type, message, stack frames, wrapped exceptions (called inner exception in dotnet)
• exception.Message only the message of the top level exception
• exception.StackTrace only the stack frames of top level exception

In error messages typically the tostring is displayed.

Note: in dotnet there is no standard way of actual/expected - each assertion fw handles it differently.

There's also something called AggregateException that is basically a wrapper of multiple (more than one) exceptions. (Used for example for async errors.) But the ToString of that displays it nicely anyway.

[mpkorstanje]

The CCK now includes the type, message and complete stacktrace with cucumber/compatibility-kit#144. The only thing left to do is to update the documentation in messages to reflect this.