3 ms·

Out of interest - what sort of objects are hard to print in this way but easy to view in a debugger?

miningape 2y ago
In my case it's basically everything since I work in java, jackson's object mapper can easily get stuck or deserialise something incorrectly if the class hasn't been annotated correctly. So it's simpler for me to pull up the debugger and I can see the "actual" data thats making up my object, it also lets me run "queries" against anything of interest (i.e. computed fields). The default toString method I've found to be useless almost every time I wanted to inspect an object in our codebase since it just prints the type + "id" for the object
- coldtea 2y ago
  >jackson's object mapper can easily get stuck or deserialise something incorrectly if the class hasn't been annotated correctly. Why should they be deserialized as JSON?
  - miningape 2y ago
    They don't have to be, but if I just want to quickly log an object to inspect it I'd rather not have to chain together a bunch of gets and prints.
    - coldtea 2y ago
      The Java language should provide an internal serialization of its structures for debug purposes capable of handling nested objects and scalars of any type ... (something like Serializable, but meant for readability, not re-loading the result and also Objects and primitives should get it automatically without declaring it). Neither JSON should be needed, not chaining together gets and prints. I guess one can do it with some reflection...
antonyt 2y ago
An object with many fields (in a language with no conveniences for it). An object tree with multiple levels of nesting. A list or dictionary of such objects. In general, print-based debugging requires a greater degree of specificity. If you know exactly what you're looking for it's great. If you are performing a more exploratory sort of debugging, a decent graphical debugger will save you a ton of time.

In my case it's basically everything since I work in java, jackson's object mapper can easily get stuck or deserialise something incorrectly if the class hasn't been annotated correctly. So it's simpler for me to pull up the debugger and I can see the "actual" data thats making up my object, it also lets me run "queries" against anything of interest (i.e. computed fields). The default toString method I've found to be useless almost every time I wanted to inspect an object in our codebase since it just prints the type + "id" for the object

coldtea 2y ago
>jackson's object mapper can easily get stuck or deserialise something incorrectly if the class hasn't been annotated correctly. Why should they be deserialized as JSON?
- miningape 2y ago
  They don't have to be, but if I just want to quickly log an object to inspect it I'd rather not have to chain together a bunch of gets and prints.
  - coldtea 2y ago
    The Java language should provide an internal serialization of its structures for debug purposes capable of handling nested objects and scalars of any type ... (something like Serializable, but meant for readability, not re-loading the result and also Objects and primitives should get it automatically without declaring it). Neither JSON should be needed, not chaining together gets and prints. I guess one can do it with some reflection...

antonyt 2y ago

An object with many fields (in a language with no conveniences for it). An object tree with multiple levels of nesting. A list or dictionary of such objects. In general, print-based debugging requires a greater degree of specificity. If you know exactly what you're looking for it's great. If you are performing a more exploratory sort of debugging, a decent graphical debugger will save you a ton of time.