There are a number of errors that are related to the interface, in which we'd like to just communicate something to the user.
E.g. when a directory is already existing, and about being overwritten, but no force has been set.
What we are doing is just to let Python fail through its exception mechanism, and throw a potentially lengthy stack trace in user's face.
This was the best possible choice in the short term, because these stack traces are as ugly as they are helpful, since they allow reconstructing the calling path.
However, for those errors that are largely expected (like the one above), we could come with a better interface, avoiding the stack trace. Possibly even in scripts.
This is just a matter of UI, and it should not affect in any way the internal workflow of the library.
The most external elements handling execution should receive the errors as they are, but filter them right before passing to the user. They can be recognized by having suitable custom exceptions, all subclassing from a single UIException, or something like that.
There are a number of errors that are related to the interface, in which we'd like to just communicate something to the user.
E.g. when a directory is already existing, and about being overwritten, but no force has been set.
What we are doing is just to let Python fail through its exception mechanism, and throw a potentially lengthy stack trace in user's face. This was the best possible choice in the short term, because these stack traces are as ugly as they are helpful, since they allow reconstructing the calling path.
However, for those errors that are largely expected (like the one above), we could come with a better interface, avoiding the stack trace. Possibly even in scripts.
This is just a matter of UI, and it should not affect in any way the internal workflow of the library. The most external elements handling execution should receive the errors as they are, but filter them right before passing to the user. They can be recognized by having suitable custom exceptions, all subclassing from a single
UIException, or something like that.