Error handling

[portnov]

Handling of errors in current sverchok is... well... not very good. To understand why the node goes red you need to switch to console and try to understand the stacktrace saying smth like "index -1 is out of bounds".
I think the big refactoring is good time to think about better way of handling errors.

[ly29]

Absolutely, even worse are nodes that hides the error so there is nothing going red at all.

[ly29]

The options seem to come down to:

• External log file, slightly better than console, open relevant part in blender text editor on error
• Pipe directly into blender text buffer
• Draw some text in the node editor

They all have their drawbacks and upside, they are not exclusive. A sensible first step would be to start using the logger module.

[portnov]

I think the most common errors are somehow related to "invalid input": wrong type of data in connected sockets, or unconnected sockets that must be connected for node to function, or invalid amount or "shape" of data. These types of errors i think could be indicated on the node itself. For example mark socket red if it is required to connect it.

[ly29]

Also now I have prepared for higher amount of pre testing, also with the Required[0] default for node function.
Some nodes might have more advanced needs of socket than on off so raising and error could also be allowed.

[0] Nothing is done with this info yet...

[ly29]

Yes, that as well, like they should turn yellow if they are missing data today, but today many nodes check themselves and quit quietly...

Agreed on red socket, and as well marking the node/s yellow to show which ones to inspect.

[zeffii]

time to employ the logging module.

[portnov]

Can we use stethoscope-like drawing to display errors?

[ly29]

Potentially yes.

[ly29]

[ly29]

The formatting might need some work and I consider writing to a text file and std err as well

[ly29]

@portnov
Something like this I guess you mean

[ly29]

Some settings for this could be in the debug panel.

[ly29]

Did some tweaking but will let further developments be based on further feedback

• print to stdout, should be stderr
• dumps error message to text file NodeTree_Error in blender text editor
• draws it using blf

[ly29]

We could also show documentation with the same infrastructure.

[portnov]

full stacktraces in node editor are not very useful imho. Can we draw just short error message there, and print full stack to text buffer?

[ly29]

A limit it to the last two lines in editor right now which gives file and error. Full trace in console and text editor.
Try and test

[ly29]

[zeffii]

i'm really really liking this.

[zeffii]

now.. if f8 worked ... holy smokes.

[ly29]

Yeah, it is getting embarrassing. Trying to sort it out now.

[ly29]

Okay so now I am starting to get a bit worried...
What happens is that the types in

If a module imports objects from another module using from ... import ..., calling reload() for the other module does not redefine the objects imported from it — one way around this is to re-execute the from
statement, another is to use import and qualified names (module.name) instead.

[ly29]

So it works now, somewhat.
Doesn't result in a lot red nodes at least.

[ly29]

Nodes can be edited.

Caveats seem to be

• no editing of the base classes, for that a restart is needed.

[zeffii]

i don't get why everything down from svrx can't simply be nixed.

[ly29]

A brief illustration of the problem.

>>> import importlib
>>> import svrx
>>> x=svrx.typing.Vertices()
>>> t=svrx.typing.Vertices
>>> isinstance(x, t)
True
>>> importlib.reload(svrx.typing)
<module 'svrx.typing' from 'c:\\Program Files\\Blender Foundation\\Blender\\2.78\\scripts\\addons\\svrx\\typing.py'>
>>> isinstance(x, t)
True
>>> t=svrx.typing.Vertices
>>> isinstance(x, t)
False
>>> type(x)
<class 'svrx.typing.Vertices'>
>>> t
<class 'svrx.typing.Vertices'>

What fails is the issubclass/isinstance checks in the parsing of the node types. There where 2-3 other problems of the same kind but they where easily resolvable.

[ly29]

@zeffii
I am thinking about nice ways to resolve this, but F8/reload is a bit of a hack in python.

[zeffii]

it's weird isn't it. that's the thing that messes with most newcomers heads. as soon as a program starts to get complex... the imports tend to become tricky to deal with (until heavy persistence makes them understood).

[zeffii]

it's almost like quantum physics. " if you think you understand quantum physics, you don't understand quantum physics" . almost.

[ly29]

I am down to three modules that can't be reloaded.