Exceptions and error

Support
#1

Hi Not sure whether I’ve been missing somthing, but if the code I’m writing into pyblish (let say an integration) raise an exception, this never gets reported, and silently go ahead.

Is there any way to make so , it at least report it as error with stacktrace ?
It would be helpful on debugging issues.

Of course, if there’s something already , sorry, and let me know !
Cheers.
L.

#2

Hi Lorenzo,

All exceptions from plug-ins are treated as errors, put into a result (as the error key) and optionally reported back to the currently running GUI.

from pyblish import api, util

class MyCollector(api.ContextPlugin):
    order = api.CollectorOrder

    def process(self, context):
        context.create_instance("MyInstance")

class MyIntegrator(api.InstancePlugin):
    order = api.IntegratorOrder

    def process(self, instance):
        raise Exception("An error")

api.register_plugin(MyCollector)
api.register_plugin(MyIntegrator)
context = util.publish()

for result in context.data["results"]:
    print("'{plugin.__name__}' was run.".format(**result))
    if result["error"]:
        print("'{instance}' had an error that said '{error}' from '{plugin.__name__}'".format(**result))
        print("  The traceback was:\n  {error.traceback}".format(**result))

Have a look at the series on reporting with results from the Lean By Example guide for more tips and tricks.

In the GUI, you’ll find them in the Terminal (for both Lite and QML) or the Perspective (for QML).

#3

Thanks Marcus,
but wouldn’t be a bit more handy to catch exceptions and report thorugh a log.error with stacktrace ?
I understand having the results, which is handy for things I know I want to report, but if there’s a bug a typo or an exception in the code, I would like to see it while it happens.

my2c

L.

#4

Yeah, this was a primary design goal for the result dictionary. It contains all of this information. pyblish-qml for example does stronger visualisation of the traceback than pyblish-lite through the Terminal and Perspective.

6021ff72-e51d-11e4-977e-7f3e643d6af4.gif468×504 1.12 MB

All of that information is provided by the same result dictionary; you could parse this yourself for bespoke use.

# Continuing on from above example
from pyblish_qml.rpc.formatting import format_error
context = util.publish()
error = context.data["results"][4]["error"]
dictionary_of_information = format_error(error)

I haven’t considered using those for exceptions, log.error is actually reserved for use through a plug-ins.

log.info("...")
log.warning("...")
log.error("...")

Would it be possible to elaborate on the benefits you see in using this for exceptions?

#5

well for me point is, having pyblish catching all the exceptions, become quite hard to see what’s going on.
so having the ability to see (thus the logging.error) what’s going wrong and keep going would help.

One option could be to have a way to not report as log.error and have it only on the report (ENV driven) ?

#6

In an ideal world, how would you prefer to see what’s going on?

#7

not much really,
just that if there’s an exception it reports it on the console (also add it to the errors message for ui convenience ?)

For me is fine to catch and continue, rather than letting the exception bubbling up , if this is the framwork design.
Cheers.
L.

#8

Ah, ok.

Yes, the GUI (pyblish-qml, mostly) is designed to give you this level of verbosity. But if nothing else, you could design such a verbose helper function for yourself.

Success   Plug-in                                   -> Instance
----------------------------------------------------------------------
1         CollectCaptainAmerica                     -> None
0         ValidateCaptainAmerica                    -> Captain America
          +-- EXCEPTION: Captain America must be a hero

Optionally, would it help to augment util.publish with a verbose=True argument? Such that it prints decisions and results by default?

#9

Are you picturing this as a sort of global flag, telling Pyblish to be more verbose and print exception messages to the console?

Maybe that could work.

If you come up with a PR for this, we could take a closer look and I’d be happy to support it.

#10

verbose=True, seems a good option, as long as it report as actual erros with stack trace,so is asier.
For the PR, I’ll see as soon as I have time.
Cheers.
L.

#11

Ok, when you, or anyone interested, is ready.

#12

thanks !
I’ll be giving it a go asap.
L.

#13

Added some tips on how to go about implementing this in the issue!