Finally, with a help of "Exception Visitor" thread I've understood the problem I've tried to spot in my previous message. In current C++ language exception handling is defined with well structured exception hierarchies in mind. In this case exception handling is simple: catch(base_exception& e) and be happy. The problem arises when one have to handle many unrelated exceptions that do not correspond to single hierarchy or even in a rare case where one needs to provide different responses for different exceptions in the same hierarchy. The first is common on subsystem boundaries like C++ - C or C++ - GUI event handlers. In the thread mentioned above two basic workarounds were described that helps to deal with a problem of many unrelated exception handling, but I believe that it can be elegantly solved on a language level. All we need is just allow the following: class A {}; class B { public : B(A const& a); }; void foo() try { throw A; } catch (B& b) { //caught } The idea behind it is simple: if A was thrown and B can be constructed from it then the catch(B& b) handler is called. With this extension one can do the following: typedef boost::variant< int, std::string > my_exception; class my_exception_visitor : public boost::static_visitor<> { public: void operator()(int & i) const { //... } void operator()(std::string & str) const { //... } }; void foo() try { if(...) throw 1; else throw std::string("Hello world!"); } catch (my_exception& e) { boost::apply_visitor( my_exception_visitor(), e ); } for filesystem it means that it can use uniform "exception handling" even without exceptions at all. versions of functions with error_code could be replaced with templates that can accept any visitor instead of error_code. It would be a high-level, type-safe, reusable and maintainable way to handle system-level errors. I'll post this idea to comp.std.c++ in a hope of it's adoption by community. But in the meantime my request to you as a filesystem and system_error developer is to use type-safe visitor approach instead of error_code. It means that you'll need to define a separate error type for each low-level error on each supported platform. Yes, it can be very annoying, but it should be done only one time. (it can be extended if the underling system error-set would be extended though) And maybe it can be automated with some text processing tools? Best, Oleg Abrosimov.