You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the _operation_wrapper treats all OSError exceptions as
"expected" in the sense that everything went fine in the filesystem itself
and that the exception was deliberately raised to encapsulate the return
value of the system call.
However, this is not necessarily true. If my filesystem tries to open some
internal files and receives an OSError, which it (errorneously) doesn't
catch, this exception should be handled as a real error in the filesystem
and not just passed on.
I therefore propose to introduce a new exception class FUSEError that is
meant exclusively for exceptions that encapsulate the return code for the
systemcalls. _operation_wrapper and LoggingMixIn should then catch only
exceptions of type FUSEError, so that OSErrors result in a full error
message with backtrace.
Original issue reported on code.google.com by Nikolaus@rath.org on 3 Jun 2009 at 6:41
The text was updated successfully, but these errors were encountered:
Actually older revisions used exactly the design you propose. I finally decided
to use OSError because it
simplified a lot many kinds of wrapper filesystems and it allows you to reuse
existing code. For example you can
see that loopback.py can use directly some of the functions in os. There is
indeed the drawback of overloading
OSError however.
I personally prefer the way it is now, but I realize the subject is debatable
and would consider switching back to
a FUSEError scheme if there is demand. However I'm not going to break
compatibility again just for this.
Original issue reported on code.google.com by
Nikolaus@rath.org
on 3 Jun 2009 at 6:41The text was updated successfully, but these errors were encountered: