Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not treat OSErrors as expected #11

Closed
GoogleCodeExporter opened this issue May 7, 2015 · 4 comments
Closed

Do not treat OSErrors as expected #11

GoogleCodeExporter opened this issue May 7, 2015 · 4 comments

Comments

@GoogleCodeExporter
Copy link

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

@GoogleCodeExporter
Copy link
Author

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 comment by verigak on 3 Jun 2009 at 8:01

@GoogleCodeExporter
Copy link
Author

I see. Would you consider making _operation_wrapper a method of the FUSE class, 
so
that one can change the behaviour by subclassing?

Original comment by Nikolaus@rath.org on 3 Jun 2009 at 9:32

@GoogleCodeExporter
Copy link
Author

Yes, this is a good suggestion.

Original comment by verigak on 3 Jun 2009 at 9:51

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Fixed in rev. 17

Original comment by verigak on 9 Jun 2009 at 4:08

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant