RE: SC_DEFAULT_ERROR_ACTIONS

I agree that we should defer any changes to SC_DEFAULT_ERROR_ACTIONS to a later time as Philipp suggests.

I recall looking into this issue around 2005 when the first LRM was written and that there was no clean, simple solution to the issues, and I think the existing LRM text in this area is basically a compromise given the behavior of the OSCI simulator.

-Stuart

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Friday, December 03, 2010 6:13 AM
To: john.aynsley@doulos.com
Cc: Bishnupriya Bhattacharya; Stuart Swan; systemc-p1666-technical@eda.org
Subject: Re: SC_DEFAULT_ERROR_ACTIONS

All,

since there haven't been any comments from the WG on this, I'd like to
start - hmm, actually rather stop the discussion on this. ;-)

  I'm opposed to change the LRM that late in the game in a rather ad-hoc
way. There are several issues with exception/SC_THROW handling in the
LRM (and consequently in the implementations) in general.

  Just recently, I prepared a document covering some of these issues to
start the discussion around this inside OSCI. The overall error /
exception handling in SystemC implementations bothers me for quite a
while, but I didn't find the time to prepare a solid proposal to P1666
in time. Additionally, there are several possible solutions which
should be discussed inside LWG first.

  If the LRM does not say anything about a reaction of the
implementation to SC_THROW, we keep all options for this discussion.

Thanks,
  Philipp

On 25/11/10 10:09, john.aynsley@doulos.com wrote:
> Bishnupriya, Stuart,
>
> Below is a transcript of an email thread of an issue you raised long ago.
> Do you want any changes made to the LRM at this point?
>
> -------
> 8.3 Page 390, very bottom. SC_DEFAULT_ERROR_ACTIONS needs SC_DISPLAY
> added in. This is a bug also in the current 2.1v1 simulator -- it needs to
> be added into sc_report.h.
>
> I've toyed with this before, its not exactly a bug, although apparently
> thats how it appears. SC_DEFAULT_ERROR_ACTIONS has SC_THROW in it and the
> error message is embedded in the exception thrown. The practice is to
> catch the exception and at that point print out the message
>
> catch( const sc_report& ex ) {
> cout << "\n" << ex.what() << "\n";
> }
>
> This is how the kernel always handles errors and the user too. It is not
> entirely unreasonable because a catch block HAS to be there for the
> program to not crash, and at that point printing out the message seems ok.
>
> Should LRM obligate ALL handlers that catch sc_reports to do a Display
> (both implementation and those in application ?) And if so shouldn't there
> be a way to insure that SC_DISPLAY action and
> sc_report_handler::handler_func is actually performed, not just stream to
> cout?
>
> Should LRM explicitly recommend that SC_THROW and SC_DISPLAY are never
> used together? Should it recommend that SC_THROW is used in isolation and
> that everything else (eg SC_LOG, SC_DISPLAY is handled by code catching
> the report ? )
> -------
>
> Thanks,
>
> John A
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.