Re: Frequently encountered errors
Quote:
Originally Posted by darwen
I can only say, I'm glad I don't use any of your software - I'd hate to be a user, be working along quite nicely and have a message box with "error 0x8020304" come up and my last 6 hours work be wiped out for no reason.
Would you be happier then, if with 6 hours work wiped you'll receive "internal error in function CreateThatSystemObject: wrong argument" message? Devastating bugs is completely different matter from spellable error messages.
Quote:
Originally Posted by darwen
I'm amazed that someone actually thinks that reporting an 0x error is acceptable.
Who is to read such errors and make some actions or decisions based on them? If it's manageble for user - such as "file not found" or "can't write to disk" - then yes, but if it's bug in software, why user need to know details? He only need a way to provide that error information to developer.
Quote:
Originally Posted by darwen
I bet you use STL and have huge memory leaks in your code you can't be bothered fixing too. And even if you wanted to fix the memory leaks, you wouldn't be able to - using STL and all.
How much would you bet? ;)
Re: Frequently encountered errors
Quote:
Originally Posted by RoboTact
No, really error doesn't need to be displayed in spellable form, there should only be the way to give developer enough hint about where the problem is. In many cases source line number/IP is enough
Unfortunatelly, in many cases the source file/line number no use even for the developer.
My example shows that, that message not use at anything even, let's say, we include __FILE__ and __LINE__ in message string.
Moreover 0x80004005 (E_FAIL) means "Unspecified error" and say nothing either to user or developer.
My given example was picked from real code in a "reports" module. That was fixed and now the user can see from time to time, let's say, "Default printer not connected" instead of "0x80004005".
You can observe not all errors are catastrophic and in more cases if they are correct handled and meaningful reported, the user can easily see that forgot something and not hurry to report it as a bug.
Re: Frequently encountered errors
Quote:
Originally Posted by RoboTact
Would you be happier then, if with 6 hours work wiped you'll receive "internal error in function CreateThatSystemObject: wrong argument" message?
Yes. At least we'll know who to poison, shoot, then hang. :D Well, I'm kidding. ;)
Re: Frequently encountered errors
Quote:
Originally Posted by RoboTact
Who is to read such errors and make some actions or decisions based on them? If it's manageble for user - such as "file not found" or "can't write to disk" - then yes, but if it's bug in software, why user need to know details? He only need a way to provide that error information to developer.
It seems you have chosen wrong examples. The real bugs are the given messages. :)
Instead, "File 'C:\MyCoolApp\imports\importx.csv' not found" and "Can't write to C: drive. Disk full" can be extremely useful for the user also.
For the real situations that concern only the devloper and not the user, the DEBUG mode (with using trace and assertion functions) was invented.
Unfortunately, many "programmers" use asserts in many wrong places like in this example.
Re: Frequently encountered errors
Well, it weren't examples, just names of error types...
What's completely wrong with that ASSERT? it's just that error isn't reported, but if it's really asserted at that point that function succeeds, it's OK. Question is if you can assert such thing.
Re: Frequently encountered errors
I gave a brief explanation HERE.
Need more, eventually snippet code, examples, demo application? ;)
Re: Frequently encountered errors
Quote:
Originally Posted by Skoons
You will never belive but some years ago I have found something like this in project which was on last test before release :eek:
Code:
p=malloc(bytes);
if(p==NULL)
{
ShowMessage("Can`t allocate enough memory");
exit(EXIT_FAILURE);
}
So this software (it was written on C language as
you see) if can`t find some more bytes for new data object closed itself, and even not ask user to save his work.
That is not because it contains only valid C code that it was written in C (of course, you have seen the true project, so, you know).
I just quoted your text to introduce the fact I found some "apparently C codes" which revealed, after a further examination, to be C++ (pass by references used somewhere for example).
Re: Frequently encountered errors
I have often seen this which can lead to problems:
if(result = DoSomeStuff( data))
{
...
}
And this is common for beginners and is particularly hard to find in order to fix:
if(this = that)
{
do_stuff();
}
Being as 'this' will become 'that' and will always equal that. So this conditional will always be true.
Maybe not a 'beginners' error:
if(object->next->value == value)
{
do_stuff();
}
When there is no reason to assume that the 'next' object actually exists...
:cool:
Re: Frequently encountered errors
Quote:
Originally Posted by Zorro3D
I have often seen this which can lead to problems:
if(result = DoSomeStuff( data))
{
...
}
You can make it clearer by saying
if ( ( result = DoSomeStuff( data ) ) != 0 )
{
...
}
I have been known not to bother to put the !=0 comparison it. It's usually obvious that you are intending to assign result and continue into the block if it's non-zero.
Quote:
And this is common for beginners and is particularly hard to find in order to fix:
if(this = that)
{
do_stuff();
}
Being as 'this' will become 'that' and will always equal that. So this conditional will always be true.
won't compile. this is not an l-value.
Quote:
Maybe not a 'beginners' error:
if(object->next->value == value)
{
do_stuff();
}
When there is no reason to assume that the 'next' object actually exists...
:cool:
and if this is done in C++ it's a beginners error to be using their own list and not std::list and algorithms. In fact it's a beginners error to use linear search in situations where either std::map or a sorted vector would be a better idea.
Re: Frequently encountered errors
I go crazy when I see something like this:
Code:
#define AFUNC1(a, b) AFunc(a, b)
#define AFUNC2(a) AFunc(a, NULL)
void AFunc(int a, const char* b)
{
// don something
}
...
AFUNC2(10);
And I've seen code like that.
And I wish I had a gun when I see things like this:
Code:
#include <iostream>
using namespace std;
#define BEGIN \
if(index<0 || index>=5) \
return; \
goo temp = _goo[index]; \
temp.Init(); \
#define END \
temp.Close();
class goo
{
public:
goo(){}
goo(const goo& cpy) {}
const goo& operator=(const goo& rval) { return *this;}
void Init() { cout << "goo::init" << endl;}
void Action() {cout << "goo::action" << endl;}
void Reaction() {cout << "goo::reaction" << endl;}
void Close() {cout << "goo::close" << endl;}
};
class foo
{
goo *_goo;
public:
foo();
~foo();
void do_something(int index);
void do_something_else(int index);
};
foo::foo()
{
_goo = new goo[5];
}
foo::~foo()
{
delete [] _goo;
}
void foo::do_something(int index)
{
BEGIN
temp.Action();
END
}
void foo::do_something_else(int index)
{
BEGIN
temp.Reaction();
END
}
int main()
{
foo f;
f.do_something(0);
f.do_something_else(4);
return 0;
}
Re: Frequently encountered errors
What do you think? This one...
Code:
for(int i = 0; i < nCount; i++)
{
try
{
// something...
}
catch(...)
{
i --; // try again
}
}
... could be funny, stupid, or it's really a bad joke?