RE: SystemC exceptions and throw_it

All,

I'm not sure what we've decided here.

I believe we have decided to recommend that user-defined exceptions thrown
with throw_it should be derived from std::exceptions, but it is not
mandated.

sc_unwind_exception is part of the standard, not user-defined, so we have
to decide whether it is derived from std::exception or not. I would
propose that it is derived from std::exception, as shown by Philipp below
(except that we do not need sc_reset_exception or sc_kill_exception). That
way it is consistent with sc_report and sc_exception.

Any objections?

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>, "Jeremiassen, Tor"
<tor@ti.com>
Cc:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>,
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
08/09/2010 13:26
Subject:
RE: SystemC exceptions and throw_it

I'm aligned with Philip here.

Thanks,
-Bishnupriya

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Tuesday, September 07, 2010 9:45 PM
To: Jeremiassen, Tor
Cc: john.aynsley@doulos.com; Bishnupriya Bhattacharya;
systemc-p1666-technical@eda.org
Subject: 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.