boost::gil::jpeg_read_dimensions(const char*) does not throw exceptions as it should

[anonymous]

boost::gil::jpeg_read_dimensions(const char*) is documented as followed (resides in .../boost/gil/extension/io/jpeg_io.hpp):

/// \ingroup JPEG_IO
/// \brief Returns the width and height of the JPEG file at the specified location.
/// Throws std::ios_base::failure if the location does not correspond to a valid JPEG file

However, it does not always throw an exception. Instead it prints an error message and exits the program, which is how libjpeg by default handle its errors.

See the following code:

#include <iostream>

#include <boost/gil/extension/io/jpeg_io.hpp>

using std::cout;
using std::cerr;
using std::endl;
using std::ios_base;

namespace gil = boost::gil;

int main(int argc, char **argv) {
  if(argc != 2) {
    cerr << "Please supply a file name." << endl;
    return 1;
  }

  const char *file = argv[1];

  cout << file << ": " << endl;

  try {
    gil::jpeg_read_dimensions(file);
  } catch(const ios_base::failure &ib_f) {
    cerr << "what: " << ib_f.what() << endl;
  } catch(...) {
    cerr << "caught other exception!" << endl;
  }

  cout << "\nDone." << endl;

  return 0;
}

I compile it using g++ 4.9.2 using the options

-std=c++11 -I/usr/local/include -L/usr/local/lib -ljpeg -o bin main.cpp

on a Mac OS X 10.9.5.

See these three runs:

$ ./bin non_existing.jpeg # this file does not exist
non_existing.jpeg: 
what: file_mgr: failed to open file

Done.

$ ./bin existing_empty.jpeg # this file exist but is empty
existing_empty.jpeg: 
Empty input file

$ ./bin existing_non_jpeg.jpeg # this file exist and is not empty, but is not a jpeg
existing_non_jpeg.jpeg: 
Not a JPEG file: starts with 0x62 0x6c

[Mateusz Loskot]

First, the printed output comes from the libjpeg. Specifically, from error_exit routine. Apparently, old GIL IO did not override it with custom non-exiting handler.

GIL in Boost 1.68 delivers completely re-implemented I/O extensions. The new version does provide custom error_exit which does not call hard exit() to abort the application, so the issue should be gone now.

Closing as fixed.

GitHub? ref: ​https://github.com/boostorg/gil/projects/4#card-12387661