Converting exceptions into expressive error messages?

Hi,

how can I make trytond stop processing and print/log/report an error message while not printing the traceback? Much like raising an exception but suppressing the traceback.

There is UserError for reporting errors caused by user input and not printing a traceback. I’m seeking for something equivalent, like HandledTrytonError.

Background

When an exception occurs in trytond, it prints the traceback. This is perfect for unexpected errors.

Anyhow, every program contains “well know error cases”, e.g. failing to create a cache file.

In such a case, an error message like “Failed to create file: …” and a respective log entry are much more helpful to the developer or sysadmin than the traceback. This error is not something that needs to be fixed in the code, thus the traceback is of not much use.

Another example are syntax or data errors in XML files listed in a module’s tryton.cfg: In this case the XML parser and validator raise meaningful exceptions. Anyhow, these get buried by several tracebacks. While this “only” effects developers being pointe to the concrete error is helpful, but the place in the code where the error occurred is of no use.

You can use something like the Sentry Tryton module. I have a talk some years ago explaining its usage:

1 Like

Thanks for this tip. Anyhow, this is not what I need: It can not decide whether the exception is “unexpected” or “well known and handled”.

For me, “well know and handled” exceptions are not exceptions but custom code.
In any of them you should have a catch part which handles the exception so it is never raised to the user.

Otherwise it is not handled right?

Not exactly.

AFAIU your case is: Handle the (non-fatal) error and continue processing in some meaningful way.

FWAW: If some (fatal) error occurs, processing of the current request needs to be terminated and the error needs to be reported to the client. Anyhow there should be no traceback.

Of course, one could log the error at the very place where it occurs. Anyhow, for terminating the current request, an exception needs to be raised anyway. Thus the error could also be logged centrally in the request-handler.

This is much like a trytond.exceptions.UserError, except that it not caused by user input.

Here is a rough example:

class MyAppError(Exception): pass

def some_deeply_nested_func(filename):
    dirname = os.path.dirname(filename)
    try:
        os.makedirs(dirname, exist_okay=True)
    except PermissionError as e:
        raise MyAppError(f"Failed to create directory {dirname}: {e}")
    with open(filename) as fh:
        return fh.read()

def dispatch_request(self, request):
    try:            
        process()
   except MyAppError as e:
        print(e, file=sys.stderr)
    except Exception as e:
        traceback.print_exc()

You can easily get an impression for what I mean by this:

  • start trytond with --dev
  • change some XML file in some module to become invalid (either invalid XML or invalid according to the scheme
  • trytond will print errors related to the invalid XML file - and also the traceback

I want to get rid of this kind of traceback.