Printing out an exception stacktrace is generally awful in a non development context.
But hiding them and printing out "failed to run" is even worse.
I've seen people do that to have a "neat output".
Don't be that person.
But hiding them and printing out "failed to run" is even worse.
I've seen people do that to have a "neat output".
Don't be that person.
I wish there was an easy way to dump core from java inside a docker container, and some sort of software for keeping track of them. Something like coredumpctl and journald, but for k8s.
The value of the core dumping has greatly diminished once commercial vendors have started stripping symbol tables from binaries they would ship (IP protection! trade secrets! know-how!), and it has diminished even greater when core dumps started approaching gigabytes in size – the reaction of system administrators was swift and cruel: «ulimit -c 0» at the system level.
[edit: i looked - it looks like a way to get cores off a machine and get a stack trace. which is nice ,but hardly changes the picture very much]
In our case, we came up with a way to assign unique codes to standard library exceptions for the language we use(.NET), custom codes for our own exceptions, and mask that with a number that roughly indicates where the exception occurred.
You end up getting codes like 0x800482c6 though which might end up frustrating users, since they have no real way to decode them.