Re: SystemC exceptions and throw_it

John,

sorry, I seem to have misremembered the consensus here.

  I don't think it's necessary to have separate classes for reset/kill
throws, although they don't harm either. Since the user usually has to
do local cleanups under both reset and kill, having only
sc_unwind_exception should be sufficient.

 I think, what's important then is to prohibit the construction of
sc_unwind_exception objects by the application, if sc_unwind_exception
is a concrete class due to implementation issues regarding error
detection of swallowing the throw or calling the scheduler.

Thanks,
  Philipp

On 07/09/10 21:59, john.aynsley@doulos.com wrote:
>
> Philipp,
>
> I believe we had agreed not to define sc_kill_exception or
> sc_reset_exception in the standard, but just have sc_unwind_exception
> with an is_reset method. Do you think differently?
>
> John A
>
> -----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
>
> To: "Jeremiassen, Tor" <tor@ti.com>
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> Date: 09/07/2010 05:15PM
> Cc: "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "bpriya@cadence.com" <bpriya@cadence.com>,
> "systemc-p1666-technical@eda.org" <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; }
> > |};
> > |
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.