0

I use serial port access with the standard open(), read(), close() functions from unistd.h (Linux).

The whole thing is wrapped with a SerialAccessor class, whose destructor wants to call close(). However, close() is not marked as __THROW, so lint complains that an exception is not caught which is a bad thing in a destructor.

The problem is: what is the correct type to catch since it is not one of the known std-classes?

This does not help, here lint states that "..." is not catched:

#include <unistd.h>

try
{
    close (fileHandle);
}
catch(...)
{ }

Anyway, I would prefer to catch a proper class / type instead of using "...".

unistd says:

/* Close the file descriptor FD.

This function is a cancellation point and therefore not marked with
__THROW.  */
extern int close (int __fd);
alk
  • 69,737
  • 10
  • 105
  • 255
Ingmar
  • 2,361
  • 3
  • 19
  • 33
  • 1
    In this particular case lint complains unreasonably. There's nothing you need to do to make your program more correct, so the solution to your problem shifts to making lint shut up. Not sure what the best way to do that would be. – Jon May 30 '14 at 09:26
  • Lint is right: the catch is useless because close will never throw anything. So instead of modifying the Lint settings, the source code should be changed – Paolo Brandoli May 30 '14 at 09:31

4 Answers4

3

close() does not throw C++ exceptions: it returns 0 on success and -1 if an error occurs.

If -1 is returned, then you have to check errno to understand what went wrong (http://linux.die.net/man/2/close)

Paolo Brandoli
  • 4,681
  • 26
  • 38
3

As close() is marked as a cancellation point, when you are running a multithreaded programs, and you call close(), another thread can gain control and cancel your thread.

This means that your thread can no longer continue to run, but the runtime system may need to do some sort of cleanup. On some O/S's, this is achieved by the system call throwing an exception which you should not catch (which also means you should be very very careful about writing catch (...) because it can catch some strange things).

See also the answers to this question

Ah: Found the one I wanted: The runtime throws the abi::__forced_unwind exception and you must rethrow it, a little like this:

try
{
    close (fileHandle);
}
catch (abi::__forced_unwind const &)
{
     throw;
}
catch(...)
{ }
Community
  • 1
  • 1
Tom Tanner
  • 9,244
  • 3
  • 33
  • 61
0
  1. EBADF - The argument supplied was not a valid file descriptor
  2. EINTR - The function call was interrupted by a signal
  3. EIO - An I/O error occurred
Pipala
  • 197
  • 1
  • 9
0

Turn off the lint warning for that line; close does not throw.

Alan Stokes
  • 18,815
  • 3
  • 45
  • 64