Re: SystemC exceptions and throw_it

Regarding sc_unwind_exception, I don't have any objections against
deriving from std::exception, although I don't see the immediate need
for it. The thrown objects won't carry any further information (e.g. in
their what() string) and are different from other errors (like
sc_report, std::runtime_error, ...) anyhow and require special treatment.

As said before, for throw_it() I would still prefer a recommendation,
instead of enforcing some coding style/good practice on the user without
a technical rationale.

My colour for the bike shed, ;-)
  Philipp

NB: The resulting sc_(unwind|rest|kill)_exception definitions:

-- // from sc_except.h

class sc_unwind_exception
  : public std::exception
{
  virtual bool is_reset() const = 0;
  virtual const char* what() const = 0; // for completeness
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; }
    virtual const char* what() const;
};

class sc_kill_exception
  : public sc_unwind_exception
{
public:
    virtual bool is_reset() const { return false; }
    virtual const char* what() const;
};

On 07/09/10 17:49, Jeremiassen, Tor wrote:
> 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.
> |
>

-- 
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.