View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
In article <d3qovm$2gl3$1@digitaldaemon.com>, zwang says...
>
>Kevin Bealer wrote:
>> GC, auto-init of data, checking of switch defaults, array bounds checking, and
>> especially null checking have been quite valuable to me for reliability.
>> 
>> GC and auto-init in particular are useful, no just because they provide
>> reliability, but because they unclutter the code.  For me a top contender for
>> bug incidence in C++ is simply that so much has to be specified, that the extra
>> syntax provides cover for broken code.
>> 
>> On another note, recently I converted an AI toy program from Java to D, then
>> tightened up the performance (by many orders of magnitude).  I simply renamed
>> the files to ".d", and was amazed to discover that after fixing the syntax
>> errors and implementing a few missing parts, there was only one code error:
>> argc was off by one (language difference).  After that, it -just ran-.
>> 
>> In other words, the syntax is very good at guiding you hand.  In C++ many many
>> things are legal code but don't do what is expected.  The D version caught
>> virtually everything at compile time.
>> 
>> Thanks, Walter.
>> 
>> Kevin
>> 
>> (P.S. If anyone wants a program to solve Sokoban puzzles in D...)
>
>Hi Kevin, I'm interested in the pruning algorithm of your Sokoban solver.

It's an A* search (I would like to do SMA*, but haven't gotten there yet.)  This
means that for every board position I need to compute a cost of completion.  The
higher number it returns, the better, as long as it never overestimates.  The
algorithm produces the optimal solution.

Pruning was originally done by checking for "stuck boxes".  Now I compute a
table of the the minimal costs from every location to every other location,
using only legal "pushes" (boxes cannot move in N unless the player can stand on
the square to the south of the box.).  This is done once at the beginning for
the entire board (it's a quick computation).

"Pruning" only happens in two ways.  First, boxes will not be pushed onto
squares that have infinite-cost (in the above table) to all target squares.

Secondly, because positions are expanded in least-cost-first order (using the
cost calculation function + existing costs), the first time you see a position
is essentially the lowest cost to get the board into that state.  So once I see
expand a board position, I never expand it again.  I keep a hash of all
previously seen board positions.

There are also several ways to relax the optimality requirement, to find a
solution sequence faster.

Kevin
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
On Wed, 13 Apr 2005 12:46:36 +0200, xs0 wrote:


[snip]
> I fail to see what the big difference is between
> 
> assert(a!==null)
> 
> and
> 
> if (a is null)
>      throw new IllegalArgumentException()
> 
> They both prevent the code that follows from running in the case where 
> the supplied parameter is null, so you can't run it with invalid 
> parameters, which is the whole purpose of those two statements.

The first is designed to detect mistakes made by the *programmer*, and the
second is designed to detect mistakes in the (user-provided) data.

> Why is it so hard for you to admit that it is possible to have CP errors 
> in code that cannot corrupt your app? 

It could be just a matter of interpretation, but Contract Programming is a
technique whose purpose is to detect mistakes made by the programmer rather
than mistakes made outside of the program - such as invalid data or
environmental constraints (e.g. out of RAM).

> I mean, if you give a plugin what 
> is basically a read-only view of your data, it shouldn't be able to 
> corrupt it. Sure it can, if it wants to, but that has nothing to do with 
> CP, exceptions, errors or whatever.
> 
> 
>> It is only 
>> the case when a contract violation has occured, because only that is 
>> a signal from the code's designer to the code's user (or rather the 
>> runtime) that the plug-in is now invalid.
> 
> That's true. However, if I have a plugin that displays tooltips on some 
> objects, I totally don't care if it encountered a CP violation or not, 
> if it works, great, if it doesn't, too bad, no tooltips anymore in this 
> session, I'll restart when I want to. But I really don't see a case for 
> forcing the app, which otherwise works perfectly, to shut down.

I've gotten confused a bit by your use of application and plug-in. I would
have thought that if a plug-in fails (CP error) then *only* the plug-in
should fail and not the application that is hosting it.


[snip]

>> So, looking back at your para "If the code of the app is able to 
>> disable the plugin without shutting down" applies to Exceptions (and 
>> Exhaustions), whereas "if it is not clear whether the app is in a 
>> consistent state, I agree shutting down completely is the best thing 
>> to do" applies to Errors. These two things hold, of course, since 
>> they are the definitions of Exceptions and Errors.
> 
> Well, who are you to decide that a CP error means an inconsistent state? 
> Sure, it does in many cases, but not necessarily always. All I'm saying 
> is that one should have a choice.

Who should have the choice? The user of the application or the designer of
the application? If the designer says "if such-and-such occurs then the
application must stop", then why should the user always have the right to
override the design?

> 
>> CP violations are never tolerated, which means they get fixed _very_ 
>> quickly.
> 
> Great, I just don't think everybody should be forced to work that way.
> 

Let's pretend that a bridge designer has placed a detection mechanism in
the bridge such that it reports an error if the load on the bridge before a
vehicle crosses is different from the load after the vehicle crosses. If it
then reports such an error, should you as a user of the bridge, have the
right to disregard the warning of a possibly unsafe bridge, or should you
be forced to wait until the bridge is declared safe again?

>>>>>I mean, when I do something like inspect a value in a debugger, 
>>>>>and the value is 150MB and the debugger runs out of memory, I 
>>>>>don't want it to stop, just because it can't show me a var (which 
>>>>>can just as easily manifest as an assertion error or whatever)...
>>>>
>>>>Out of memory is not an error, it's an exception, so that's just 
>>>>not an issue.
>>>
>>>Like I said, out of memory can just as well manifest itself later 
>>>as a broken contract or whatever.
>> 
>> 
>> No, it cannot.
> 
> Sure it can:
> 
> int[] allocIfYouCan(int size)
> {
>      try {
>          return new int[size];
>      } catch (OutOfMemory ignored) {
>          return null;
>      }
> }
> 
> void doSomething(int[] arr)
> {
>     assert(arr!==null);
> }
> 
> doSomething(allocIfYouCan(10000000));
> 
> Obviously, allocIfYouCan() is not a good idea, but it can still happen.

But by using the 'assert', the designer/coder is saying that at *anytime* a
null is returned then the application is broken and thus needs to be fixed
before it can be used.

If the coder does not mean that, then the coder needs to avoid using
'assert' in this type of situation. Use a simple runtime 'if' statement
instead.

[snip]

>>  [snip]
>  > So (hopefully) you see that it is impossible to ever state
>  > (with even practical certainty) that "a faulty part of the
>  > application should not be taken as if the whole application
>  > is faulty".
> 
> No, I don't.. There are parts and there are parts. You're saying that 
> even the tiniest error (but only if it was specified in a contract) 
> should abort the app, I'm just saying that in some cases it's possible 
> for that to be overreacting.
> 

Yes, it may be possible for an application to continue running to the
user's satisfaction after a program contract has been broken. However, one
can never be absolutely sure in every case. And because it is a broken
program contract, it means that the designer of the application *wants* the
program to stop. It is her program after all ;-)

>>>OK, it is obviously desired in some cases, so I agree it should be 
>>>supported by the language, BUT, none of the built-in exceptions 
>>>should then be unrecoverable.
>> 
>> Well again, I get the feeling that you think I've implied that a 
>> wide range of things should be unrecoverable. I have not, and 
>> perhaps I should say so explicitly now: AFAIK, only contract 
>> violations should be Errors (i.e. unrecoverable), since only they 
>> are a message from the author(s) of the code to say when it's become 
>> invalid. 
> 
> How has the code become invalid exactly? The code doesn't change when it 
> violates a contract.

Because the designer said that if such a situation ever happens, then it is
because the programmer has made a mistake. And thus, the rest of the
program may contain errors that are not so obvious. It is a red-flag that
says that the application is suspect and needs to be corrected or at least
re-validated before continuing.


-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
17/04/2005 8:50:45 AM
April 16, 2005
Re: recoverable and unrecoverable errors or exceptions
>> Why is it so hard for you to admit that it is possible to have CP errors 
>> in code that cannot corrupt your app?
>
>    In principle it is not so.
>    In practice it often is (albeit you cannot know).
>
> I've said that a hundred times.
>
> If you want me to say that, in principle, there are CP errors that cannot 
> corrupt your app, then I won't because it ain't so. There's a beguiling 
> thought that preconditions can be classed in that way, but it doesn't pan 
> out. (And I'm not going to blather on about that because I think 
> everyone's heartily sick of the debate by now. I know I am <g>)

I'm not sure how to differentiate principle and practice. For example
 int return1(){ return 0; } // written by an intern
 void user_code() {
   int x = return1();
   assert( x == 1 );
   printf("I got a 1.\n");
 }
Now the code above will assert every time and obviously no real code would 
look exactly like that but it's not uncommon to see asserts check something 
that if it fails can be easily recovered from. Is returning 0 from a 
function that says it returns 1 a contract violation? yes. Is it a big deal? 
it depends.
April 17, 2005
Re: recoverable and unrecoverable errors or exceptions
Derek Parnell wrote:
> On Wed, 13 Apr 2005 12:46:36 +0200, xs0 wrote:
> 
> 
> [snip]
> 
>>I fail to see what the big difference is between
>>
>>assert(a!==null)
>>
>>and
>>
>>if (a is null)
>>     throw new IllegalArgumentException()
>>
>>They both prevent the code that follows from running in the case where 
>>the supplied parameter is null, so you can't run it with invalid 
>>parameters, which is the whole purpose of those two statements.
> 
> 
> The first is designed to detect mistakes made by the *programmer*, and the
> second is designed to detect mistakes in the (user-provided) data.

Hmm, I'd disagree. If a function does such a check, I'd say its contract 
is obviously that it doesn't work with nulls. It doesn't matter whether 
that's in the in block or start of body, and it doesn't matter whether 
it's an assert or an if(). So, both are mistakes by the programmer, 
because the function shouldn't be called with null..


>>Why is it so hard for you to admit that it is possible to have CP errors 
>>in code that cannot corrupt your app? 
> 
> It could be just a matter of interpretation, but Contract Programming is a
> technique whose purpose is to detect mistakes made by the programmer rather
> than mistakes made outside of the program - such as invalid data or
> environmental constraints (e.g. out of RAM).

I agree with that, I just don't agree that in case of _any_ contract 
violation, the app should be forced to terminate (which is what Matthew 
wants).

> I've gotten confused a bit by your use of application and plug-in. I would
> have thought that if a plug-in fails (CP error) then *only* the plug-in
> should fail and not the application that is hosting it.

Me too, that's my whole point :) But Matthew seems to think otherwise..


>>>So, looking back at your para "If the code of the app is able to 
>>>disable the plugin without shutting down" applies to Exceptions (and 
>>>Exhaustions), whereas "if it is not clear whether the app is in a 
>>>consistent state, I agree shutting down completely is the best thing 
>>>to do" applies to Errors. These two things hold, of course, since 
>>>they are the definitions of Exceptions and Errors.
>>
>>Well, who are you to decide that a CP error means an inconsistent state? 
>>Sure, it does in many cases, but not necessarily always. All I'm saying 
>>is that one should have a choice.
> 
> Who should have the choice? The user of the application or the designer of
> the application? If the designer says "if such-and-such occurs then the
> application must stop", then why should the user always have the right to
> override the design?

Hmm, now I see how that sentence can be confusing :) "you" refers to 
Matthew, while "one" refers to "any coder". The answer is definitely 
designer.


> Let's pretend that a bridge designer has placed a detection mechanism in
> the bridge such that it reports an error if the load on the bridge before a
> vehicle crosses is different from the load after the vehicle crosses. If it
> then reports such an error, should you as a user of the bridge, have the
> right to disregard the warning of a possibly unsafe bridge, or should you
> be forced to wait until the bridge is declared safe again?

Perhaps I should be, but if everybody was forced to stay off it (for 
example, by some shield from Star Trek, so you really can't get on), how 
will they ever fix it? :)


>>int[] allocIfYouCan(int size)
>>{
>>     try {
>>         return new int[size];
>>     } catch (OutOfMemory ignored) {
>>         return null;
>>     }
>>}
>>
>>void doSomething(int[] arr)
>>{
>>    assert(arr!==null);
>>}
>>
>>doSomething(allocIfYouCan(10000000));
>>
>>Obviously, allocIfYouCan() is not a good idea, but it can still happen.
> 
> 
> But by using the 'assert', the designer/coder is saying that at *anytime* a
> null is returned then the application is broken and thus needs to be fixed
> before it can be used.

I don't think all asserts assert that the application is broken. For 
example:

Image i=ImageLoader.load("c:\\foo.tif");
assert(i);
processImage(i);

I'd say that the assertion is not "if i is ever null, kill the whole 
application", it's just "if i is ever null, I don't want to continue".


But that was not the point. I tried to make the point, that not all CP 
violations should mean that the application should be forced to 
terminate. A consequence, if one agrees, is that assert should not throw 
exceptions that cannot be "quenched", because all CP support in D 
depends on assert. OTOH, I totally support critical_assert, a new type 
of exception, or whatever, to make the apps, that actually do require 
unquenchable exceptions, implementable.



> If the coder does not mean that, then the coder needs to avoid using
> 'assert' in this type of situation. Use a simple runtime 'if' statement
> instead.

Perhaps, but like I said, I don't see any difference between assert(a) 
and if(!a) throw.. Obviously, they will throw different exceptions, but 
both should be quenchable.


>>No, I don't.. There are parts and there are parts. You're saying that 
>>even the tiniest error (but only if it was specified in a contract) 
>>should abort the app, I'm just saying that in some cases it's possible 
>>for that to be overreacting.
> 
> Yes, it may be possible for an application to continue running to the
> user's satisfaction after a program contract has been broken. However, one
> can never be absolutely sure in every case. And because it is a broken
> program contract, it means that the designer of the application *wants* the
> program to stop. It is her program after all ;-)

If the designer wants the app to stop, that's ok. It's also ok if she 
doesn't want the app to stop. Matthew says it's never ok to not stop, 
and I disagree..


>>How has the code become invalid exactly? The code doesn't change when it 
>>violates a contract.
> 
> 
> Because the designer said that if such a situation ever happens, then it is
> because the programmer has made a mistake. And thus, the rest of the
> program may contain errors that are not so obvious. It is a red-flag that
> says that the application is suspect and needs to be corrected or at least
> re-validated before continuing.

It may or it may not contain errors. Sometimes you don't know, but 
sometimes you also do. Especially when dealing with user data (which is 
almost always :), it's often hard to predict all the ways that data can 
be wrong (I work in GIS; you wouldn't believe how many _different_ types 
of errors 600 million polygons can contain :). If that principle is 
acknowledged throughout the code (by making data structures robust, 
updating transactionally, always handling exceptions, and whatnot), one 
can implement the app so that it is totally able to recover from any 
'error' it detects later on. Now, I don't see why such an app should be 
forced to terminate, if someone decided to assert (a<100000000) 
somewhere and that happens to not be true every now and then?


xs0
April 17, 2005
Re: recoverable and unrecoverable errors or exceptions
On Sun, 17 Apr 2005 07:36:44 +0200, xs0 wrote:

> Derek Parnell wrote:
>> On Wed, 13 Apr 2005 12:46:36 +0200, xs0 wrote:
>> 
>> 
>> [snip]
>> 
>>>I fail to see what the big difference is between
>>>
>>>assert(a!==null)
>>>
>>>and
>>>
>>>if (a is null)
>>>     throw new IllegalArgumentException()
>>>
>>>They both prevent the code that follows from running in the case where 
>>>the supplied parameter is null, so you can't run it with invalid 
>>>parameters, which is the whole purpose of those two statements.
>> 
>> 
>> The first is designed to detect mistakes made by the *programmer*, and the
>> second is designed to detect mistakes in the (user-provided) data.
> 
> Hmm, I'd disagree. 

So let's see if I got it straight. You disagree that the purpose of the
'assert' mechanism is detect mistakes made by the programmer, as opposed to
detecting bad data. 

>If a function does such a check, I'd say its contract 
> is obviously that it doesn't work with nulls. It doesn't matter whether 
> that's in the in block or start of body, and it doesn't matter whether 
> it's an assert or an if(). So, both are mistakes by the programmer, 
> because the function shouldn't be called with null..

It may be true that the function should never be called with a null.
However, if that is the case then assert should also not be used as the
detection/reporting mechanism. This is because, as a general rule, assert
should be used on output data rather than on input data. Assert should be
used to detect errors in *logic* rather than errors in *data*.

Assert should be used to validate that the programmer's implementation of
an algorithm is correct. Argument validation is looking at the inputs to an
algorithm and not its results. 

I say 'assert' should be used because if there is a logic error then the
program should shutdown as safely as it can and not continue, and the
'assert' is one such mechanism that has that behaviour.

> 
>>>Why is it so hard for you to admit that it is possible to have CP errors 
>>>in code that cannot corrupt your app? 
>> 
>> It could be just a matter of interpretation, but Contract Programming is a
>> technique whose purpose is to detect mistakes made by the programmer rather
>> than mistakes made outside of the program - such as invalid data or
>> environmental constraints (e.g. out of RAM).
> 
> I agree with that, I just don't agree that in case of _any_ contract 
> violation, the app should be forced to terminate (which is what Matthew 
> wants).

By definition, a contract failure means that we have a situation in which
somebody needs to revalidate things. I suggest that you have seen evidence
of people using contracts when contracts ought not to have been used.
Instead, a run-time test other than a contract should have been used.

>> I've gotten confused a bit by your use of application and plug-in. I would
>> have thought that if a plug-in fails (CP error) then *only* the plug-in
>> should fail and not the application that is hosting it.
> 
> Me too, that's my whole point :) But Matthew seems to think otherwise..
> 
I believe that Matthew was saying that if a plug-in fails in such a manner
that one cannot guarantee that the hosting application is untouched, then
the application should shutdown too.

>>>>So, looking back at your para "If the code of the app is able to 
>>>>disable the plugin without shutting down" applies to Exceptions (and 
>>>>Exhaustions), whereas "if it is not clear whether the app is in a 
>>>>consistent state, I agree shutting down completely is the best thing 
>>>>to do" applies to Errors. These two things hold, of course, since 
>>>>they are the definitions of Exceptions and Errors.
>>>
>>>Well, who are you to decide that a CP error means an inconsistent state? 
>>>Sure, it does in many cases, but not necessarily always. All I'm saying 
>>>is that one should have a choice.
>> 
>> Who should have the choice? The user of the application or the designer of
>> the application? If the designer says "if such-and-such occurs then the
>> application must stop", then why should the user always have the right to
>> override the design?
> 
> Hmm, now I see how that sentence can be confusing :) "you" refers to 
> Matthew, while "one" refers to "any coder". The answer is definitely 
> designer.
> 
In which case, the assert should shutdown the application unconditionally.

>> Let's pretend that a bridge designer has placed a detection mechanism in
>> the bridge such that it reports an error if the load on the bridge before a
>> vehicle crosses is different from the load after the vehicle crosses. If it
>> then reports such an error, should you as a user of the bridge, have the
>> right to disregard the warning of a possibly unsafe bridge, or should you
>> be forced to wait until the bridge is declared safe again?
> 
> Perhaps I should be, but if everybody was forced to stay off it (for 
> example, by some shield from Star Trek, so you really can't get on), how 
> will they ever fix it? :)

I don't know as that is not my field, but I guess they won't be asking you
either. 

>>>int[] allocIfYouCan(int size)
>>>{
>>>     try {
>>>         return new int[size];
>>>     } catch (OutOfMemory ignored) {
>>>         return null;
>>>     }
>>>}
>>>
>>>void doSomething(int[] arr)
>>>{
>>>    assert(arr!==null);
>>>}
>>>
>>>doSomething(allocIfYouCan(10000000));
>>>
>>>Obviously, allocIfYouCan() is not a good idea, but it can still happen.
>> 
>> 
>> But by using the 'assert', the designer/coder is saying that at *anytime* a
>> null is returned then the application is broken and thus needs to be fixed
>> before it can be used.
> 
> I don't think all asserts assert that the application is broken. For 
> example:
> 
> Image i=ImageLoader.load("c:\\foo.tif");
> assert(i);
> processImage(i);
> 
> I'd say that the assertion is not "if i is ever null, kill the whole 
> application", it's just "if i is ever null, I don't want to continue".
> 
Then don't use an 'assert' then! This is really a simple thing, honestly.

** If you want to shutdown an application when you detect an error in
logic, use an assert.

** If you do not want to shutdown an application when you detect an error
(of any sort), do not use an assert.

> But that was not the point. I tried to make the point, that not all CP 
> violations should mean that the application should be forced to 
> terminate.  A consequence, if one agrees, is that assert should not throw 
> exceptions that cannot be "quenched", because all CP support in D 
> depends on assert. OTOH, I totally support critical_assert, a new type 
> of exception, or whatever, to make the apps, that actually do require 
> unquenchable exceptions, implementable.
> 

> 
>> If the coder does not mean that, then the coder needs to avoid using
>> 'assert' in this type of situation. Use a simple runtime 'if' statement
>> instead.
> 
> Perhaps, but like I said, I don't see any difference between assert(a) 
> and if(!a) throw.. Obviously, they will throw different exceptions, but 
> both should be quenchable.

Using D today, how would you code something to throw an unquenchable
exception?

> 
>>>No, I don't.. There are parts and there are parts. You're saying that 
>>>even the tiniest error (but only if it was specified in a contract) 
>>>should abort the app, I'm just saying that in some cases it's possible 
>>>for that to be overreacting.
>> 
>> Yes, it may be possible for an application to continue running to the
>> user's satisfaction after a program contract has been broken. However, one
>> can never be absolutely sure in every case. And because it is a broken
>> program contract, it means that the designer of the application *wants* the
>> program to stop. It is her program after all ;-)
> 
> If the designer wants the app to stop, that's ok. It's also ok if she 
> doesn't want the app to stop. Matthew says it's never ok to not stop, 
> and I disagree..

If the designer wants it to stop, she uses an assert. If she allows the
possibility of it continuing, then she does not use an assert.

>>>How has the code become invalid exactly? The code doesn't change when it 
>>>violates a contract.
>> 
>> 
>> Because the designer said that if such a situation ever happens, then it is
>> because the programmer has made a mistake. And thus, the rest of the
>> program may contain errors that are not so obvious. It is a red-flag that
>> says that the application is suspect and needs to be corrected or at least
>> re-validated before continuing.
> 
> It may or it may not contain errors. Sometimes you don't know, but 
> sometimes you also do. Especially when dealing with user data (which is 
> almost always :), it's often hard to predict all the ways that data can 
> be wrong (I work in GIS; you wouldn't believe how many _different_ types 
> of errors 600 million polygons can contain :). If that principle is 
> acknowledged throughout the code (by making data structures robust, 
> updating transactionally, always handling exceptions, and whatnot), one 
> can implement the app so that it is totally able to recover from any 
> 'error' it detects later on. Now, I don't see why such an app should be 
> forced to terminate, if someone decided to assert (a<100000000) 
> somewhere and that happens to not be true every now and then?

Don't use an assert then. Use a different mechanism.

-- 
Derek Parnell
Melbourne, Australia
17/04/2005 4:09:39 PM
April 17, 2005
Re: recoverable and unrecoverable errors or exceptions
> [snip, summary:]
> Then don't use an 'assert' then! This is really a simple thing, honestly.
> 
> ** If you want to shutdown an application when you detect an error in
> logic, use an assert.
> 
> ** If you do not want to shutdown an application when you detect an error
> (of any sort), do not use an assert.
> 
>> [snip]
>
> Don't use an assert then. Use a different mechanism.

But I want to use assert, even if perhaps my examples were not the best 
cases for using it (if nothing else, "assert(a)" is far less characters 
than any sort of "if(a) throw ...", and it also leaves no doubt on what 
is and isn't expected). I just fail to see why using assert would have 
to mean that my app needs to shut down whenever one fails.

I mean, if you want to shutdown, you can do it easily - don't quench 
assertion failures, how hard is that?

OTOH, if assert was unquenchable, there would be no way not to shutdown, 
and I'm always pro-choice :)

BTW, why shouldn't assert be used to check data? If you look at
http://www.digitalmars.com/d/dbc.html
it would seem that I'm not the only one that thinks it's ok to do so 
(and to catch those errors, too).. I mean, an error in data somewhere 
means an error in logic somewhere else, anyway..


xs0
April 17, 2005
Re: recoverable and unrecoverable errors or exceptions
xs0 wrote:
>> Don't use an assert then. Use a different mechanism.
> 
> But I want to use assert, even if 

Assert exists for the very purpose of halting the entire program when 
the assertion fails.

One might even say that "assert" is a concept. And that concept is then 
implemented in quite a few languages.

D should not be the one language which destroys the entire concept.
April 17, 2005
Re: recoverable and unrecoverable errors or exceptions
On Sun, 17 Apr 2005 11:24:21 +0200, xs0 wrote:

>  > [snip, summary:]
>> Then don't use an 'assert' then! This is really a simple thing, honestly.
>> 
>> ** If you want to shutdown an application when you detect an error in
>> logic, use an assert.
>> 
>> ** If you do not want to shutdown an application when you detect an error
>> (of any sort), do not use an assert.
>> 
>  >> [snip]
>  >
>> Don't use an assert then. Use a different mechanism.
> 
> But I want to use assert

Well that's a shame then.

>, even if perhaps my examples were not the best 
> cases for using it (if nothing else, "assert(a)" is far less characters 
> than any sort of "if(a) throw ...", and it also leaves no doubt on what 
> is and isn't expected). I just fail to see why using assert would have 
> to mean that my app needs to shut down whenever one fails.

Hang around a bit longer, it'll come to you eventually.

> I mean, if you want to shutdown, you can do it easily - don't quench 
> assertion failures, how hard is that?
> 
> OTOH, if assert was unquenchable, there would be no way not to shutdown, 

Exactly!  Now you're getting it.

> and I'm always pro-choice :)

Like ... fclose() shouldn't always close the file if I don't want it to?
    ... sometimes I might not want function X to return any value but
sometimes I might?

The purpose of assert, the reason it exists, is to shutdown programs when
the programmer chooses to.

> BTW, why shouldn't assert be used to check data? If you look at
> http://www.digitalmars.com/d/dbc.html
> it would seem that I'm not the only one that thinks it's ok to do so 
> (and to catch those errors, too).. I mean, an error in data somewhere 
> means an error in logic somewhere else, anyway..

Duh?! Of course it checks data, but it ought to check *output* data and not
*input* data. The output data is a result of *your* coding and you need to
check to see if you implemented the algorithm correctly. That is what
assert is designed for. The input data may or may not have come from your
code. It could have come from external sources such as users of your
program. You shouldn't crash a program with assert if the input data is
bad. You may crash it by some other mechanism though. Assert is a debugging
mechanism; that is, it is used to find bugs (specifically your coding
errors) before people get to use your program. A production program, one
compiled with the -release switch, will not execute any assert statements
in your code.

/me shakes head and walks away. 

-- 
Derek Parnell
Melbourne, Australia
17/04/2005 9:03:07 PM
April 17, 2005
Re: Robust, fault-tolerant software is easier to write with D than C++. Or is it? [was: Re: recoverable and unrecoverable errors or exceptions]
In article <d3q20d$1oag$1@digitaldaemon.com>, Matthew says...
>
>The only area of doubt as to the viability of this solution is what
>would happen with heterogeneous mixes of dynamically merged link
>units. That is, what happens if a CP process loads a (violating)
>non-CP plug-in? It just crashes without invoking the graceful
>shutdown / logging stuff, I guess. Conversely, if a non-CP process
>loads a (violating) CP plug-in? Same thing happens, I guess. I'm
>interested in people's thoughts on this.

Perhaps it would be worthwhile to have some metadata built into libraries?  It
might be useful to be able to query this kind of thing at load-time.


Sean
April 17, 2005
Re: recoverable and unrecoverable errors or exceptions
In article <d3qn6o$2fbf$1@digitaldaemon.com>, Walter says...
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message
>news:d3qdtc$23js$1@digitaldaemon.com...
>> GC, auto-init of data, checking of switch defaults, array bounds checking,
>and
>> especially null checking have been quite valuable to me for reliability.
>>
>> GC and auto-init in particular are useful, no just because they provide
>> reliability, but because they unclutter the code.  For me a top contender
>for
>> bug incidence in C++ is simply that so much has to be specified, that the
>extra
>> syntax provides cover for broken code.
>
>Yes. For example, most declarations in C++ have to be done twice.
>Differences can inadvertently creep in. This is not what one would expect to
>see in a modern language. Just being able to express directly what you want
>to be done improves the reliability of the code, as you wrote.

Related question.  Would you suggest relying on the default initializers when
the default value is acceptable or is always initializing variables the
preferred method?  I ask this because of comments you've made in the past that
you'd prefer if variables were all default initialized to trap values rather
than "usable" values.  Basically, I'm finding myself beginning to rely on
integral variables default initializing to 0 and not bothering to explicitly
initialize them, and I don't want to fall into this habit if there's any chance
of the default values changing.


Sean
7 8 9 10 11 12 13 14 15
Top | Discussion index | About this forum | D home