[
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295383#comment-14295383
]
Bastiaan Stougie commented on THRIFT-2717:
------------------------------------------
A proposal for an additional small improvement for C++.
For any generated exception class, e.what() currently always returns "Default
TException.". Instead, the generated code of the exception class could
implement a what() that returns a string with the actual (namespace and) name
of the exception class in it.
This change would make it possible to catch a base class, for example
::apache::thrift::TException, and to log something that identifies the exact
exception type.
Typical use case: additional exception types may be introduced in a thrift spec
that some existing code that uses an API may not be aware of yet. If the
existing code can log the exception type by catching a base class, this would
help a lot with debugging.
> C++V2 generator/library
> -----------------------
>
> Key: THRIFT-2717
> URL: https://issues.apache.org/jira/browse/THRIFT-2717
> Project: Thrift
> Issue Type: New Feature
> Components: C++ - Compiler
> Reporter: Konrad Grochowski
>
> instead of adding another set of options to 'old' cpp generator I've started
> creating new one in:
> https://github.com/hcorg/thrift/tree/cpp_v2
> using old as an reference
> main goals (for generator):
> * code compatible with old librart (at least for first tests, new lib and
> compiler switches can be added later)
> * no more ugly {{__isset}} structure -> boost::optional for optional values
> * as a result - no more {{__}} in names, which violates C++ standard
> * all generation code will have own unit tests (TDD used wherever possible)
> * generated types headers independent from Thrift header, to allow other
> layers of application using generated types without dependency leaks
> * each type will generate own header/cpp file - easier for user to include
> only used parts.
> * unordered map/sets
> * returning using move semantics, no more ugly 'return via output parameter'
> (still possible as option thou - sometimes it's needed for performance)
> * async client using boost::future
> * enum classes
> * initializer lists for constants (maybe)
> main goals (for library):
> * minimizing boost deps
> * using C++11 features to simplify lib
> * be base for new generator
> I'm aiming in C++11 subset available in gcc 4.8 and MSVC 2013
> currently I have only complete enum generation, but work is in progress
> all comments etc are very welcome :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
