On Friday 24 February 2006 00:35, Jeff Hill wrote:
> Subject 2) A severity returning function verses an augmented
> exception hierarchy.
>
> Of course the trade off here is more or less catch phrases in the
> exception handler.
>
> Case A:
>
> Catch ( warning & )
> {
> }
> Catch ( error & )
> {
> }
> Catch ( severe & )
> {
> }
>
> Case B:
>
> Catch ( Exception & e ) {
> Print e.what ()
> Print ( e.severity() )
> }
>
> Now, admittedly, if Ben is right and we only need really to track two
> situations {unexpectedFault, externalConditionInfluencedFault} then
> there would need to be only two catch phrases. That can't be
> difficult.
Hi Jeff,
I think it is even easier: you normally /don't/ handle the
'unexpectedFault' exception. You let it crash. Ah, well, that needs to
be qualified:
What I mean is that such exceptions should not be handled in the
overwhelming majority of cases. There will be one place where it makes
sense to catch such an exception, namely in the supervisor/init thread
that has set up and started the component that failed unexpectedly.
Because this is the only place where we have all the necessary
information to restart such a component.
Code that only invokes services of a component (like CA) should only
handle the expected (external) conditions.
Ben
- Navigate by Date:
- Prev:
RE: 3.15 C++ Exception classes Jeff Hill
- Next:
XML is dead, long live ML9 Benjamin Franksen
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Fwd: Re: 3.15 C++ Exception classes Benjamin Franksen
- Next:
XML is dead, long live ML9 Benjamin Franksen
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|