RE: SystemC exceptions and throw_it

I think that if it is to look and behave as an exception it should derive from the standard exception class. Given that it is an "exception" and not a common case event, the overhead of throwing it should not be material.

If it is not derived from std::exception, we need to give these types different names that do not give the impression that these are "exceptions".

Best regards,

Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com
|-----Original Message-----
|From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-
|technical@eda.org] On Behalf Of Philipp A. Hartmann
|Sent: Tuesday, September 07, 2010 6:31 AM
|To: john.aynsley@doulos.com
|Cc: bpriya@cadence.com; systemc-p1666-technical@eda.org
|Subject: Re: SystemC exceptions and throw_it
|
|John,
|
|On 07/09/10 12:37, john.aynsley@doulos.com wrote:
|
|> 1666-2005 has sc_report derived from std::exception, and for backward
|> compatibility includes:
|>
|>         typedef std::exception sc_exception;
|>
|> Should we mandate or recommend that user-defined exceptions thrown by
|> throw_it are derived from std::exception?
|
|Although it might be good practice in some cases, I would prefer not to
|require derivation from std::exception.  The thrown exceptions might be
|used in similar scenarios (merely as tagged types) as sc_kill_exception
|et.al., which do not need the overhead of std::exception.
|
|  We could recommend it, though.  Especially if the exception is
|uncaught, the implementation can actually provide some information about
|the thrown object, if it is derived from a known interface.
|
|> Would someone care to provide me with a definition of class
|> sc_unwind_exception?
|
|I've played around with the detection of completely swallowed kills and
|resets, and have used the definitions attached below.
|
|  Note, that in this case, sc_unwind_exception is not derived from
|std::exception and requires polymorphic usage in the catch clauses
|(since it's abstract and does not have a public (copy) constructor).
|
|  The constructors/destructor might not be needed in the standard, but
|are used in the implementation to do the error checking.
|
|Greetings from Oldenburg,
|  Philipp
|
|-- // from sc_except.h
|
|class sc_unwind_exception
|{
|  virtual bool is_reset() const = 0;
|protected:
|  sc_unwind_exception();
|  sc_unwind_exception( const sc_unwind_exception& );
|  virtual ~sc_unwind_exception();
|};
|
|class sc_reset_exception
|  : public sc_unwind_exception
|{
|public:
|    virtual bool is_reset() const { return true; }
|};
|
|class sc_kill_exception
|  : public sc_unwind_exception
|{
|public:
|    virtual bool is_reset() const { return false; }
|};
|
|--
|Philipp A. Hartmann
|Hardware/Software Design Methodology Group
|
|OFFIS
|R&D Division Transportation | FuE-Bereich Verkehr
|Escherweg 2 * 26121 Oldenburg * Germany
|Phone/Fax: +49-441-9722-420/282 * PGP: 0x9161A5C0 * http://www.offis.de/
|
|
|--
|This message has been scanned for viruses and
|dangerous content by MailScanner, and is
|believed to be clean.
|
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.