Differential D2684
Better handling of fatel errors Authored by Isaac Weaver (wisaac) on May 24 2017, 5:25 AM. Tags None Subscribers None
Details
The fatal() function always raises a RuntimeErrorand the exception is caught in the cli wrapper. Because bam/cli.py will never be run as main it makes no sense to check if it's main in the fatal() function. Would it be better to catch all exceptions and handle them in this way (and possibly print the stacktrace to a log file somewhere) so it's nicer from the user standpoint when it fails?
Diff Detail
Event TimelineComment Actions The fatal() function (please double-check for typos) just hides the raising of exceptions. In my opinion, we should be using custom exception subclasses for BAM, and not rely on raising Exception or RuntimeError. Comment Actions So you are saying fatal () would just raise a BamException (or maybe BamFatalError) but the printing of those errors is still handled in bam_cli.py? Comment Actions I'm saying that we should remove fatal() altogether and directly raise a BamException, or maybe use a more specific subclass of BamException that's appropriate for the cause of the error and/or the context the error occurs in. Comment Actions I updated it to raise BamException instead of calling fatal(). It would be very easy to add more specific sub-classes of BamException and handle those differently if needed. For now I just kept everything as BamException. Comment Actions Accepting the revision, with the note that Blender Asset Manager has been superseded (at least here in the Blender studio) by Blender Asset Tracer. BAM hasn't seen any development in a while. |