Re: SC_DEFAULT_ERROR_ACTIONS

David, all,

to avoid any confusions here: I'm also in favour of the verbosity
proposal for sc_reports (in particular SC_INFO, etc).

  The SC_DEFAULT_ERROR_ACTIONS, I've been referring to in the mail you
reply to, are related to the behaviour of an implementation under the
SC_THROW action. This is a different kettle of fish and should IMHO not
be changed for now.

Greetings from Oldenburg,
  Philipp

On 03/12/10 18:07, David C Black wrote:
> Would you mind sharing your thoughts with me? I am currently in favor of
> Cadence verbosity proposal, but perhaps if I saw a bit more of your
> perspective (not to debate its merits), I would be convinced to change my
> mind and postpone.
>
> On Fri, Dec 3, 2010 at 8:13 AM, Philipp A. Hartmann <
> philipp.hartmann@offis.de> wrote:
>
>> 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.
>>
>>
>>
>

-- 
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://www.offis.de/
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.