Hacker News Reader

Comment by mehrdadn | Hacker News Reader

> It's only through exceptions that you can have meaningful copy-constructable resource-holding value types.

Could you give an example of this specifically? Are you thinking of e.g. a File class whose constructor opens the file? Because every such example I can think of is one where it ultimately seems inappropriate to me to use exceptions to signal the error. Both from a conceptual standpoint (it might be something you have no control over, so it's not a programmer error) and from a performance standpoint. Example for the latter: say the user gives you a list of hundreds of thousands of files that are to be copied somewhere "if they exist". Imagine half of them don't exist. Now your program is going to have to run through hundreds of thousands of exceptions to signal this.

View on HN

That file class might hold a file descriptor and dup the file descriptor in the copy constructor. If that dup operation fails because you've hit the FD descriptor limit and that copy constructor has no way of indicating that it failed to do its job, you're screwed.

Sure, you can give up on copy constructors altogether and manually manage resource copies, but doing so impoverishes the language, wrecks one of its best features, and makes programs both more verbose and probably a bit slower.

Sure, you can do this, but don't. Approximately the last thing you want is a copy constructor that can fail.

If you have to do an OS call to duplicate the underlying resource, assume the class isn't copyable in this way. It's almost certainly possible to make it moveable, and this will get you the bulk of the benefit: you can return it from functions, and you have a std::vector of it.

(Also worth noting that close (2), which presumably you'd call from the destructor, can fail with EIO or EINTR. I don't consider looping on EINTR ever safe, but that's up to you. EIO, on the other hand - what are you going to do about that? And if you don't call close from the destructor, what the hell use is this class anyway?? Overall, I don't think value objects make very good wrappers for a POSIX-style file descriptor.)

> Sure, you can do this, but don't.

It was instructive. That said, there's nothing wrong in general with a class that owns a file descriptor, and making this class copy constructible as a legitimate design decision.

> Also worth noting that close (2), which presumably you'd call from the destructor, can fail with EIO or EINTR.

IO errors from close(2) should be ignored. If you care about durability, call fsync before you close. Even if close "fails" with an IO error, the underlying FD is still closed. EINTR does not actually happen.

See extensive discussion http://austingroupbugs.net/view.php?id=529

A common pattern for dealing with failures on construction, such as the example above, without using exceptions is for the object to be constructed in a null state (often useful in any case) and implementing a 'explicit operator bool()' overload that evaluates to false if construction failed or is intentionally null. Of course, that means you have to actually check that construction was successful, similar to returning an error code. It doesn't require you to give up copy constructors etc if they are sensible (and these are usually, but not always, best served by move constructors).

But how is requiring the programmer to know that he has to check error codes and whatnot any different from requiring the call be place in a try/catch block?

Most cases where exceptions are useful are when the alternative is knowingly causing such a state that will inevitably lead to a seg fault. It's much easier to raise at the point of failure instead of trying to limp until the application eventually crashes or loses you all your money.

Your code isn't really statically typed if every object might support its declared methods, or might instead be an unusable time-bomb. Much better that an invalid object never exists and code that needs that object isn't reachable.

Exceptions are not for handling programmer errors. Assertions are.

Exceptions are indeed used for handling exceptional situations such as actual errors. If you only want to copy a file it it exists, then check if it exists (race-prone but fast) or create a function that copies a file only if it exists.

Or you know, swallow the nonexistence exception. An optimizing compiler might be able to elide the throw statement if it is inlining the copy function.

The only issue seems to be that few people are able to install or create a good top level error handler in case there is an actual unhandled failure.

> Exceptions are not for handling programmer errors. Assertions are.

std::logic_error?

That is not a programmer error, this is a domain error mostly for math functions or string parsing. (Other than relatively evil std::length_error/out_of_range which might go either way.)

In most cases where it is a bit gratuitously thrown it can be avoided.

You might want as well to redefine any error as a programmer error.

> That is not a programmer error, this is a domain error mostly for math functions or string parsing.

....what in the world? no... for domain errors there's, erm, std::domain_error. C++ Reference/StackOverflow/MSDN/etc. already explain all these. But it seems I have to copy-paste them here?

"Domain and range errors are both used when dealing with mathematical functions." [1]

"std::logic_error reports errors that are a consequence of faulty logic within the program such as violating logical preconditions or class invariants and may be preventable." [2]

"std::domain_error may be used by the implementation to report domain errors, that is, situations where the inputs are outside of the domain on which an operation is defined." [3]

[1] https://stackoverflow.com/a/641972

[2] http://en.cppreference.com/w/cpp/error/logic_error

[3] http://en.cppreference.com/w/cpp/error/domain_error

Sure they are :) I think that, together with std::optional and futurestd::expected could be a very robust error handling strategy for C++.

Reply on news.ycombinator.com