#Exit code 11 clion how to#
Stated this way, the problem seems very similar to the parallel issue of controlling whether and how to log messages logged from various libraries. render the exception a bit differently), and so on.
Or maybe it wants to do some special handling with some subset of these exceptions from package1 (e.g. Maybe an application wants exceptions like these from package1 to show a traceback, but exceptions from package2 to use the simpler behavior. Unless I’m not fully understanding the proposal, one possible wrinkle or problem I see is that, in cases where exceptions like these are being raised from libraries, how the exception should be handled might depend not just on the code raising the exception, but also on how the application is using the library and what the application wants the UX to be like. To frame it slightly differently, I’m suggesting that code raising an exception should be able to provide a hint for how the exception behaves if it is not handled. This whole area is hard to get right, and I’m very much in favour of anything that makes it easier to write user-friendly error handling - but IMO it’s very much an area where “as simple as possible but no simpler” (my emphasis) applies. Rather than calling sys.exit, it should be raising a library-specific exception, something like argparse.InvalidArgs and leave the decision to exit to the caller.Īs far as suppressing the traceback is concerned, my experience is that displaying tracebacks to the user is a lousy UI, so I agree that a friendly message is the right way to go - but not having the traceback when an error occurs is a complete PITA, so throwing the traceback away at the interpreter level seems wrong to me - the application should decide what to do with the traceback data (put it in a log file, offer an “extra details” option to the user, or whatever. I’d say this sounds more like a bug in argparse (or at least a bad design decision). argparse currently calls sys.exit() if there are problems with the arguments it’s parsing - this is making an assumption about the context in which it’s called. So what I’m suggesting is a standard means for code raising an exception to indicate that if this goes uncaught and is shown to the user, the error message should provide enough detail about the problem without a traceback, without necessarily telling the application that it should quit.Į.g. What’s wrong with defining the exception type and handling it in the application, as I already do? It’s OK so long as the code raising the exception is part of the application, but if the parsing/validation happens in a separate library, there’s no standard way to do this. web applications might want to map InputError exceptions to HTTP 4xx errors.
an interactive GUI where it’s appropriate to display an error message but not exit.
SystemExit is a special exception type for cleanly exiting a running program, and catching it is a code smell, not least because it pushes developers towards extreme measures if they really want to exit. Why don’t I use SystemExit, which already behaves this way? Mostly gut feeling, but I’ll try to justify that a bit. This would come with an override, an environment variable or a python command line option that would show the normally-hidden traceback. So my proposal is that Python’s default excepthook should do something similar - either with a new built-in exception type such as InputError, or some parameter or attribute you can set on any exception to suppress the traceback (akin to the existing _suppress_context_ attribute). This is analogous to the difference between HTTP 5xx errors (something went wrong on the server) and 4xx errors (the client made a ‘bad’ request in some way).
Sys.exit(str(e)) # Print the message to stderr and exit with status 1 The traceback to the code that raised them isn’t important, so the top level of my code does something like this to hide tracebacks for those errors: try: When writing command line applications, I often end up defining some classes of ‘input error’, which relate to bad input - from command line arguments, config files, etc.
0 kommentar(er)
