Currently if an exception is thrown in while drawing the inspector, BD seems to swallow it without logging to the console.
This makes identifying issues with the inspector and custom drawers extremely difficult, as not only is finding the source harder but it is sometimes not obvious that there is an issue at all! Leading to heisenbugs for edge cases that are difficult to repro. This most often crops up with errors in custom drawers, but not always.
Attaching a debugger and enabling the "break on any exception/break on handled exceptions" setting is pretty much the only efficient way to identify the issue without taking stabs in the dark. But I only know to do that if I know/guess that there's an exception being thrown somewhere
Example
In one of our Actions, we have a custom class and a list of elements of that custom class. The custom class has two string fields that don't have a default value and are therefore initialised to null. When trying increasing the size of the list, it silently fails; the list length remains the same. However, decreasing the size of the list works as expected. At this point I assume something is going wrong with element init. One of these string fields has a custom drawer attribute but this happens with or without the custom drawer defined.
I attach the debugger as described above. Lo and behold, we have a handled exception with a bunch of
Identifying the cause of this issue caused time lost for myself and another engineer, they came to me with the issue and then we both spent time finding the root and working around it. If BD logged exceptions it catches we could have fixed it immediately and it would allow us to quickly get a stack trace to report here for issues like this that don't stem from a custom drawer.
This makes identifying issues with the inspector and custom drawers extremely difficult, as not only is finding the source harder but it is sometimes not obvious that there is an issue at all! Leading to heisenbugs for edge cases that are difficult to repro. This most often crops up with errors in custom drawers, but not always.
Attaching a debugger and enabling the "break on any exception/break on handled exceptions" setting is pretty much the only efficient way to identify the issue without taking stabs in the dark. But I only know to do that if I know/guess that there's an exception being thrown somewhere
Example
In one of our Actions, we have a custom class and a list of elements of that custom class. The custom class has two string fields that don't have a default value and are therefore initialised to null. When trying increasing the size of the list, it silently fails; the list length remains the same. However, decreasing the size of the list works as expected. At this point I assume something is going wrong with element init. One of these string fields has a custom drawer attribute but this happens with or without the custom drawer defined.
I attach the debugger as described above. Lo and behold, we have a handled exception with a bunch of
TaskInspector and FieldInspector in the callstack, success! From this I can see that somewhere along the line the BD inspector code is calling into Activator.CreateInstance, which actually does not work for strings. Apparently this is due to string not having a default constructor. After changing our custom class to init our string fields to "" the problem goes away and we can increase the size of our list again, yay.Identifying the cause of this issue caused time lost for myself and another engineer, they came to me with the issue and then we both spent time finding the root and working around it. If BD logged exceptions it catches we could have fixed it immediately and it would allow us to quickly get a stack trace to report here for issues like this that don't stem from a custom drawer.
