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

Reduce nesting of try-catch construct in "encode_parcels"? #1123

Closed
elfring opened this Issue May 2, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@elfring
Contributor

elfring commented May 2, 2014

A nested try-catch construct is used in the function "encode_parcels".

  • Would a single one be sufficient at this place?
  • Can any C++ compiler generate better code with one nesting level less?
@K-ballo

This comment has been minimized.

Show comment
Hide comment
@K-ballo

K-ballo May 2, 2014

Member

The catch at L246 will catch exceptions thrown from the inner catch blocks, specifically L242

Member

K-ballo commented May 2, 2014

The catch at L246 will catch exceptions thrown from the inner catch blocks, specifically L242

@elfring

This comment has been minimized.

Show comment
Hide comment
@elfring

elfring May 2, 2014

Contributor

I do not see a need for the catch-all clause to be specified by a separate try statement there.

Contributor

elfring commented May 2, 2014

I do not see a need for the catch-all clause to be specified by a separate try statement there.

@hkaiser hkaiser added this to the 0.9.9 milestone May 2, 2014

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser May 2, 2014

Member

The comment says it:

            // We have to repackage all exceptions thrown by the
            // serialization library as otherwise we will loose the
            // e.what() description of the problem, due to slicing.

However, we could write it as:

    // ...
    catch (boost::exception const&) {
        LPT_(fatal)
            << "encode_parcels: "
               "caught boost::exception";
        hpx::report_error(boost::current_exception());
        return buffer;
    }
    catch (std::exception const& e) {
        try {
            // We have to repackage all exceptions thrown by the
            // serialization library as otherwise we will loose the
            // e.what() description of the problem, due to slicing.
            boost::throw_exception(boost::enable_error_info(
                hpx::exception(serialization_error, e.what())));
        catch (...) {
            LPT_(fatal)
                    << "encode_parcels: "
                   "caught unknown exception";
            hpx::report_error(boost::current_exception());
            return buffer;
        }
    }
    catch (...) {
        LPT_(fatal)
                << "encode_parcels: "
               "caught unknown exception";
        hpx::report_error(boost::current_exception());
        return buffer;
    }

which isn't much better.

Member

hkaiser commented May 2, 2014

The comment says it:

            // We have to repackage all exceptions thrown by the
            // serialization library as otherwise we will loose the
            // e.what() description of the problem, due to slicing.

However, we could write it as:

    // ...
    catch (boost::exception const&) {
        LPT_(fatal)
            << "encode_parcels: "
               "caught boost::exception";
        hpx::report_error(boost::current_exception());
        return buffer;
    }
    catch (std::exception const& e) {
        try {
            // We have to repackage all exceptions thrown by the
            // serialization library as otherwise we will loose the
            // e.what() description of the problem, due to slicing.
            boost::throw_exception(boost::enable_error_info(
                hpx::exception(serialization_error, e.what())));
        catch (...) {
            LPT_(fatal)
                    << "encode_parcels: "
                   "caught unknown exception";
            hpx::report_error(boost::current_exception());
            return buffer;
        }
    }
    catch (...) {
        LPT_(fatal)
                << "encode_parcels: "
               "caught unknown exception";
        hpx::report_error(boost::current_exception());
        return buffer;
    }

which isn't much better.

@hkaiser hkaiser closed this May 2, 2014

@hkaiser hkaiser added the tag: wontfix label May 2, 2014

@hkaiser hkaiser self-assigned this May 2, 2014

@elfring

This comment has been minimized.

Show comment
Hide comment
@elfring

elfring May 2, 2014

Contributor

@hkaiser: I find the merging of catch handlers as you showed it a bit cleaner.

Contributor

elfring commented May 2, 2014

@hkaiser: I find the merging of catch handlers as you showed it a bit cleaner.

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