throwUnexpected() should create a stack trace

Description

If we hit an unexpected exception it would sometimes be very useful to know the stack of calling functions to work out how it got there.

Conclusion

None

Activity

Show:

Gavin Halliday September 25, 2014 at 9:10 AM

Since Richard is convinved I'll accept the bug. Target to 5.2 because it would be useful, and I think it is a simple change.

Richard Chapman September 25, 2014 at 7:52 AM

Do you know what the ops team generally search for when they are looking for evidence (in a log file) that a node "cored" ?

Jacob Cobbett-Smith September 24, 2014 at 2:04 PM

Could make it more explicit at same time as this throwUnexpected() change.

Jacob Cobbett-Smith September 24, 2014 at 2:03 PM

Core stacks (as caught by SEH handler) begin with :
"====================================================="

Richard Chapman September 24, 2014 at 1:57 PM

Ok, fine, you convinced me. So long as the new function does not cause the code to grow.

Is there any way of making sure that stack traces we provoke deliberately are clearly differentiated (e.g. by inexperienced ops guys) from the ones that result from cores?

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Components

Assignee

Reporter

Priority

Fix versions

Created August 14, 2014 at 9:49 AM
Updated November 21, 2014 at 2:02 PM
Resolved November 21, 2014 at 2:02 PM

Flag notifications