www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Casting an expression to bool means testing for 0 or !=0 for arithmetic types

reply Pluto <pluto planets.not> writes:
This part has always bothered me. Could somebody please explain to me the
rationale behind limiting functions to one usable error code?

if(function())
~~
:Pluto
Jul 31 2010
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 31.07.2010 23:44, Pluto wrote:
 This part has always bothered me. Could somebody please explain to me the
 rationale behind limiting functions to one usable error code?

 if(function())
 ~~
    

futher you'd just reinvent switch statement. which if perfectly OK for it, here it goes: switch(function()){ case ERR_CODE1: // --- break; case ERR_CODE2: // --- break; // --- default: // --- break; } Honestly, I'd suggest using exceptions instead of error codes. Usage of error codes scales poorly and itself is very error-prone, also killing the return value of functions just for error code leads to very awkward design.
 :Pluto
    

-- Dmitry Olshansky
Jul 31 2010
next sibling parent Pluto <pluto planets.not> writes:
== Quote from Dmitry Olshansky (dmitry.olsh gmail.com)'s article
 On 31.07.2010 23:44, Pluto wrote:
 This part has always bothered me. Could somebody please explain to me the
 rationale behind limiting functions to one usable error code?

 if(function())
 ~~

futher you'd just reinvent switch statement. which if perfectly OK for it, here it goes: switch(function()){ case ERR_CODE1: // --- break; case ERR_CODE2: // --- break; // --- default: // --- break; }

But these aren't compatible for the same function. Defining false as <1 would fix this.
 Honestly, I'd suggest using exceptions instead of error codes.
 Usage of error codes scales poorly and itself is very error-prone, also
 killing the return value of functions just for error code leads to very
 awkward design.

~~ :Pluto
Jul 31 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Saturday 31 July 2010 16:22:46 Pluto wrote:
 But these aren't compatible for the same function.
 Defining false as <1 would fix this.

Historically, false has always been 0 and true non-zero - probably because it's then easy to use the assembly instruction to check whether something is 0 (which I believe is cheaper than checking for a specific value). In any case, changing that would likely break both people's expectations and their code. And regardless of that, it _isn't_ an error code to have a function return whether it succeeded or not. If you want to check error codes, then check for specific values or actually use the returned value rather than just throughing it in a condition by itself. _Every_ type converts to bool when put in a condition statement. It's entirely consistent that way. And having 0 be false and 1 true for numeric types is entirely consistent with how things have historically worked and pretty much everyone will expect them to work. Changing that would cause far more problems than it would ever solve. If you want error codes, you can just check the return value against 0 like has historically been done and you're fine, but error codes are generally a poor choice anyway. - Jonathan M Davis
Jul 31 2010
prev sibling next sibling parent reply Jason Spencer <spencer8 sbcglobal.net> writes:
== Quote from Dmitry Olshansky (dmitry.olsh gmail.com)'s article
 Honestly, I'd suggest using exceptions instead of error codes.

This seems to be an increasingly common but still expensive suggestion for error handling. Unless D has made great strides in exception performance (which is entirely possible), I still believe that, where performance is anything like an issue anyway, exceptions should be used only for truly exceptional condition--not alternate flow that could/should be expected. But I'm not just being a curmudgeon; I also have a suggestion. If you really want to take different paths based on a function return, make that return an object. This is what exceptions do, but it need not be so expensive. You could have a generic return class that has a string, a value, and casts to bool to give you most of what exceptions and bool return types give. But you can also sub-class that class and add polymorphic behavior to avoid the switch on value. Or make it a singleton and not pass it back. Or have one for each important call path, to which every called function can add delegates to run onError() or run deferred at some root level. Some of this would be a lot of work to setup, but I find it pretty generic. I should probably make a library and post it. For the stuff that most folks use exceptions for (i.e. to hold a string,) this class is easy to write, and costs must less at run-time. I will freely allow the critique that if do you this, then you'd have to check the return object after each call to see if there's error handling required. But I see this as a chief benefit for the maintainer (usually me in 6 months after I've forgotten everything about the code.) It spells out that there is another code path that's important to consider when changing things. Letting exceptions go by tends to obfuscate that. For out of memory, sure throw and don't catch. But for input string didn't parse, you want to handle that safely, informatively, gracefully, or whatever your robustness requirements are. So make it clear to someone that it needs to be handled. I see a lot of exception-unsafe code. I think programmers often don't appreciate that your function may suddenly return between any two arbitrary function calls, and almost between any two arbitrary statements. You have to really design carefully for exceptions. So it turns out this problem is a tough one and requires effort no matter what. Just a thought. Jason
Jul 31 2010
next sibling parent Pluto <pluto planets.not> writes:
== Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 On Saturday 31 July 2010 20:15:58 Jason Spencer wrote:
 == Quote from Dmitry Olshansky (dmitry.olsh gmail.com)'s article

 Just a thought.
 Jason

solution in most cases. When dealing with an error, it's likely to either be related to I/O (be it an actual I/O error or input from a user or file) or a logic error in the code.

whether it was just bad code (looks like it though) but there are probably some examples where people really don't know what kind of data they are handling and use std.conv to try. Not really sure about that now that I think about it. ~~ :Pluto
Aug 01 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jason Spencer Wrote:
 Unless D has made great strides in exception
 performance (which is entirely possible),

From my tests dmd exceptions are more than ten times slower than Oracle-Java ones. I have test code. Bye, bearophile
Aug 01 2010
prev sibling parent Jason Spencer <spencer8 sbcglobal.net> writes:
== Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 For logic errors, efficiency isn't really an issue, since they
 shouldn't be happening. If they are, go fix your code and it won't
 be an issue.

That gets less true as the cost of a try block goes up. Even if logic errors never occur, the infrastructure to check for them costs you something. Ever compared the performance of a program w/ and w/o trys? So, would you advocate for exceptions as the sole error reporting mechanism? Return values are just for valid result values and everything else is an exception? Where do you personally draw the line? Jason
Aug 01 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Saturday 31 July 2010 20:15:58 Jason Spencer wrote:
 == Quote from Dmitry Olshansky (dmitry.olsh gmail.com)'s article
 

 
 Just a thought.
 Jason

I honestly don't think that exception handling is a particularly expensive solution in most cases. When dealing with an error, it's likely to either be related to I/O (be it an actual I/O error or input from a user or file) or a logic error in the code. For logic errors, efficiency isn't really an issue, since they shouldn't be happening. If they are, go fix your code and it won't be an issue. For I/O-related errors, I/O is already slow. You can't expect that to be efficient anyway. And if you're get an I/O error, you have a problem that has to be dealt with, and efficiency probably isn't an issue at that point anyway. The main issue with exceptions is whether code handles them correctly, and that's just as true of error codes. Particularly when you add RAII and scope into the mix, it's really not all that bad. There's always the issue over checked exceptions with there being pros and cons both ways, but overall, I'm definitely pro-exceptions and anti-error handling. I really do think that it makes for better code and that efficiency really isn't an issue in most cases. Maybe if you're dealing with embedded code, it might matter. But beyond something like that, exceptions will be better. As for how to use exceptions, I really think that Java does it quite well and is a good role model overall. It's just the checked exceptions that are particularly debatable. Your suggestion isn't necessarily bad, but I really don't think that there's anything wrong with using exceptions and that having to deal with errors explicitly like you would with error codes or your suggestion just clutters code and makes it less maintainable. - Jonathan M Davis
Jul 31 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Pluto <pluto planets.not> wrote:

 This part has always bothered me. Could somebody please explain to me the
 rationale behind limiting functions to one usable error code?

Well, traditionally it was done because testing for 0/non-0 is a simple and fast operation. Also, boolean logic can be thought of as simple maths, as AND is multiplication and OR is addition. This only makes sense if false == 0. As for having more error codes, why would you use an int for it? Would it not be more logical to use an enum, and to explicitly test for the value upon return? Why not use exceptions? If the problem is that enums are non-extensible, and exceptions are too heavy, many libraries use the convention that 0 means success, and anything else is an error code. -- Simen
Jul 31 2010
parent reply Pluto <pluto planets.not> writes:
== Quote from Simen kjaeraas (simen.kjaras gmail.com)'s article
 Pluto <pluto planets.not> wrote:
 This part has always bothered me. Could somebody please explain to me the
 rationale behind limiting functions to one usable error code?

and fast operation.

 Also, boolean logic can be thought of as simple maths,
 as AND is multiplication and OR is addition. This only makes sense if
 false == 0.

It even makes it more symmetrical.
 As for having more error codes, why would you use an int for it? Would it
 not be more logical to use an enum, and to explicitly test for the value
 upon return? Why not use exceptions?
 If the problem is that enums are non-extensible, and exceptions are too
 heavy, many libraries use the convention that 0 means success, and
 anything else is an error code.

Jul 31 2010
parent Pluto <pluto planets.not> writes:
== Quote from Simen kjaeraas (simen.kjaras gmail.com)'s article
 Pluto <pluto planets.not> wrote:
 == Quote from Simen kjaeraas (simen.kjaras gmail.com)'s article
 Pluto <pluto planets.not> wrote:
 This part has always bothered me. Could somebody please explain to me

 rationale behind limiting functions to one usable error code?

and fast operation.


jnz <label>; vs cmp EAX 0; jg <label>;

 Also, boolean logic can be thought of as simple maths,
 as AND is multiplication and OR is addition. This only makes sense if
 false == 0.

It even makes it more symmetrical.

Let's start out with a false value f of -1. Now AND it with itself (f * f), and you get 1, which is true. This does not seem correct.

f is an integral, not a boolean. For it to work like a boolean it needs a cast, implicit or explicit: cast(bool); >0?true:false if(returnsErrorCodes()); implicit cast from return value to bool f*f; integral operation and should return the multiplication f&f; bitwise operation and should return bitwise AND cast(bool) f & cast(bool) f; bitwise operation on booleans ~~ :Pluto
Aug 01 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Pluto <pluto planets.not> wrote:

 == Quote from Simen kjaeraas (simen.kjaras gmail.com)'s article
 Pluto <pluto planets.not> wrote:
 This part has always bothered me. Could somebody please explain to me  

 rationale behind limiting functions to one usable error code?

and fast operation.


Likely not. But the assembly is easier: jnz <label>; vs cmp EAX 0; jg <label>;
 Also, boolean logic can be thought of as simple maths,
 as AND is multiplication and OR is addition. This only makes sense if
 false == 0.

It even makes it more symmetrical.

How? Let's start out with a false value f of -1. Now AND it with itself (f * f), and you get 1, which is true. This does not seem correct. -- Simen
Jul 31 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Sunday 01 August 2010 07:36:27 Jason Spencer wrote:
 == Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 
 For logic errors, efficiency isn't really an issue, since they
 shouldn't be happening. If they are, go fix your code and it won't
 be an issue.

That gets less true as the cost of a try block goes up. Even if logic errors never occur, the infrastructure to check for them costs you something. Ever compared the performance of a program w/ and w/o trys? So, would you advocate for exceptions as the sole error reporting mechanism? Return values are just for valid result values and everything else is an exception? Where do you personally draw the line? Jason

It really depends on what you're doing. I do think that exceptions are the better way to go, but it tends to be dangerous to say things like "always" and "never." Generally, however, I would use return for valid results only and use exceptions for errors. However, if error cases become very likely, then exceptions do tend to become a poorer solution since you don't want to be throwing lots of exceptions. Also, there are cases where you can take an error and simply turn it into a default value (particularly for things like parsing and conversion functions) if that's acceptable. Still, I think that it generally makes for better code when you assume that the returned data is correct and then let exceptions deal with the error cases - particularly when dealing with user input and file I/O. And in such cases, efficiency is not generally the greatest concern. If you had cases where efficency was a great concern, then it might be worth looking at whether exceptions were the best way to handle things, but in the general case, I believe that they are. As to where exactly I draw the line, I'd really have to look at the code in question to make any kind of judgement call. However, I'm generally going to go with exceptions unless I have a good reason not to, and I've found such reasons to be fairly rare. - Jonathan M Davis
Aug 01 2010