| View previous topic :: View next topic |
| Author |
Message |
Ant
Joined: 06 Mar 2004
Posts: 306
Location: Canada
|
 Posted: Sat Jun 30, 2007 12:49 pm Post subject: asserts are useless |
 |
|
As we all know asserts are completely useless (well, of course not) 
I'm going to give an alternate version to some asserts eg:
| Code: |
version(noAssert)
{
if ( gdkPixbuf is null )
{
int zero = 0;
version(Tango)
{
Stdout("struct gdkPixbuf is null on constructor").newline;
}
else
{
printf("struct gdkPixbuf is null on constructor");
}
zero = zero / zero;
}
}
else
{
assert(gdkPixbuf !is null, "struct gdkPixbuf is null on constructor");
}
|
so (soon) use the version = noAssert if you like asserts as much as I do.
if you don't know the arithmetic exception is catched by a debugger and you can inspect the stack trace.
Ant |
|
| Back to top |
|
 |
Auria
Joined: 29 May 2006
Posts: 44
|
| Posted: Sun Jul 01, 2007 9:04 am Post subject: |
|
|
when i use C++ i define my own assert to cause an arithmetic exception with aq #define...
e.g.
#define myAssert( condition, message ) if(!(condition)) {std::cout << message; int x=0/0;}
isn't that possible in D, perhaps with a function or an 'alias' ? that would make much less mess in the source code |
|
| Back to top |
|
|
Ant
Joined: 06 Mar 2004
Posts: 306
Location: Canada
|
| Posted: Sun Jul 01, 2007 9:28 am Post subject: |
|
|
| Auria wrote: | when i use C++ i define my own assert to cause an arithmetic exception with aq #define...
e.g.
#define myAssert( condition, message ) if(!(condition)) {std::cout << message; int x=0/0;}
isn't that possible in D, perhaps with a function or an 'alias' ? that would make much less mess in the source code |
probably it's possible. I know it's ugly and I'm open to suggestions.
I've got suggestions some time ago on what to do but still it was easier to do it that way.
Please notice if you don't use "version=noAssert" no changes are made.
Please notice all the source code is generated automatically so it can be change in minutes if a better suggestion is offered.
PS something went wrong as I still got the assert instead of the exception on a recent run of my current project...
Ant |
|
| Back to top |
|
|
Auria
Joined: 29 May 2006
Posts: 44
|
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Tue Aug 14, 2007 3:59 am Post subject: |
|
|
Finally installed Feisty Fawn, and updated to the tangofied version of gtkD. It took quite a bit of work, as I've got lot's of things that I need for my app, and I can't reproduce most of them with the automatic bindings generator. So, I kind of have my own branch of gtkD, which is a mess. And every time I merge with the gtkD subversion, it takes a long time to get all working again... (But I changed into using git now, so it might be easier in the future... I hope.)
Here's some thoughts and questions:
This assert thing hit me immediately. Here's a snippet of my old code, before assertions in constructors:
| Code: |
Caps caps = pad.getCaps();
//This actually never get's caught as the D Caps isn't null
//while the underlying C struct might still be...
if( caps is null )
{
debug(Discoverer) Stdout("Discoverer.newDecodedPadCb() pads caps are null. Somethings wrong here. Skipping.").newline;
trytogetnegcaps = true;
}
//This is what you had to do, to know if the C struct was null
//or not... It's kind of ugly, isn't it.
else if( caps.getCapsStruct() is null )
{
debug(Discoverer) Stdout("Discoverer.newDecodedPadCb() THIS IS YOUR WORST NIGHTMARE. caps.getCapsStruct is null.").newline;
trytogetnegcaps = true;
}
|
So, this is a basic case, where you try to getCaps() from a pad in GStreamer. Then you're supposed to check if the Caps are null or not. So, in GStreamer and I believe in GTK+ also, it's many times the case that our D constructors will get GstType* that is null. Because that's the way to tell in C, that something went wrong.
So if we do an assert on every D constructor, it doesn't make sense, as it is very common for this to happen (AFAIK).
The optimal solution for me would be to have the constructor somehow set the D object to null, when it get's a null C object. Something like this in pseudo code, because this propably isn't possible?:
| Code: |
this(GdkPixbuf* gdkPixbuf)
{
if( gdkPixbuf is null )
this = null;
else do stuff...
}
|
The other solution would be to not check anything on the constructor, but have a method in every gtkD class called something like:
| Code: |
bool isNull()
{
if( getGdkPixbufStruct() is null )
return false;
else return true;
}
|
In that case the user would have to check for if( mypixbuf.isNull ) after creating one. That would not be at all that bad.
Then there's the exceptions. Why do you need to use the arithmetic exception? I tested it, but I can't seem to find a way to catch the exception in my code??. Why can't you just use a normal "throw new Exception". Of course it will result in ugly code for the user, when you have to do try and catch everywhere...
But, my point was, that asserts are not good there, as they will end the program without an option for the coder to know about the error. (If I understand asserts correctly that is...) And it is normal for the C objects to be null. You just have to check if that's the case...
The current state has made my app unusable for the moment. It will crash in an assert error or an arithmetic exception as soon as I try to use GStreamer... |
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Sun Nov 11, 2007 5:51 pm Post subject: |
|
|
My app still doesn't work with the current version of gtkD from SVN. It was August, when I asked about it. And now it's November, and there still isn't any discussion about the issue that I posted above.
There hasn't been any changes in the gtkD svn for 3 months now. And the last change by Ant was 4 months ago.
So what's happening with the exceptions and asserts? What's happening with gtkD? How are you doing Ant? Busy with other stuff?
I know I haven't contributed to the svn either. But I really don't know much about coding! (What a poor excuse...)
Here's a long list of things that I'd like to see happen in gtkD in the near future (defined as 6 months):
1. remove the old Duit files from svn, so that people won't get mixed up by them. No-one is ever going to know to look inside a folder named /trunk/gtkD/src/ when there's /trunk/src/ available.
2. Rename gtk.GtkD to gtk.Main as I suggested in here: http://www.dsource.org/forums/viewtopic.php?t=2770
(Ignore the namespaces suggestion... I don't think it is good to suggest it as default, but it should be mentioned somewhere that it it possible!)
Other option (in my opinion) would be gtk.Application.
But this is not a major issue. I just don't like how GtkD.init() and import gtk.GtkD; look like.
3. GtkD.main() should be renamed to Main.run(). (Or Application.run()...). But again, this is not a big issue.
4. The enums should be automatically public imported by all files. (And the enums should propably be in a file of their own then). You shouldn't need to import gtkc.gtktypes to get the enums. That would be a lot cleaner.
5. there should be a file that will public import all files in the specific part of gtkD (just like /src/GtkD.d, but... ) like: import gtk.All, import gdk.All, import glib.All; etc. Or something like that.
6. class cairoLib.Cairo should be renamed to cairo.Context.
7. DSSS should be used for building gtkD. I've written the dsss.conf file for it, and it's really really easy to use it. You can get it from a post of mine:
http://www.dsource.org/forums/viewtopic.php?t=3059&start=0.
Or from the new wiki page for it: http://www.dsource.org/projects/dui/wiki/BuildingWithDSSS
8. The DSSS building would look a bit cleaner if we had the following directory structure:
/src
/gtkD
/gtkDgl
/gstreamerD
dsss.conf
/wrap
That's because if we have a dir called src, srcgl and srcgstreamer, DSSS will internally copy those files to a dir called /usr/local/include/d/src/ etc. Which looks a bit nasty. (In my suggestion it would be /usr/local/include/d/gtkD.)
9. The signals and slots should somehow be made better. I'm no expert on this (I'm no expert on anything...) so it would be nice if someone with some experience with them would show up, and write a suggestion how it should be done.
10. Oh, I can't think of number ten...
I think most of these things are easy to do. They're just renaming and cleanup suggestions. They would (in my very humble opinion) make this project a bit more approachable, more professional, better, more standards compliant with other GTK+ bindings, and (did I mention it already) - better.
I know that there's only a handful of people who have ever contributed to this project, and that Ant has practically done it all by himself. And that everybody has very little time these days. But I still hope it could somehow be done. (If it isn't done, I'll do it myself...  ) And if it can't or shouldn't be done, I at least would want some discussion why this is the case.
So, more discussion please... 
Overall, I think gtkD has some very good code in it. It would just need that little extra work to be a really really good alternative for writing GUI code in D, and even in GTK+ and the Gnome world. |
|
| Back to top |
|
|
Ant
Joined: 06 Mar 2004
Posts: 306
Location: Canada
|
| Posted: Wed Nov 21, 2007 11:53 pm Post subject: |
|
|
| satelliittipupu wrote: | ... And the last change by Ant was 4 months ago.
... |
I need some vacations  its been a year since...
and right now I don't have any project that uses gtkD.
Ant |
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Thu Nov 22, 2007 1:33 am Post subject: |
|
|
| Ant wrote: |
I need some vacations its been a year since...
and right now I don't have any project that uses gtkD.
Ant |
Yes. That's understandable... Everybody needs some time off. |
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Sat Dec 01, 2007 7:00 am Post subject: |
|
|
I tested my earlier null proposition and it does seem to work really easily. Setting this = null; will set the object to null. You really can just do:
| Code: |
this(GdkPixbuf* gdkPixbuf)
{
if( gdkPixbuf is null )
{
this = null;
return;
}
else do stuff...
}
|
It will just cleanly set the newly created object (this) to be null. So. Instead of asserts and exceptions we should just do that, when the incoming gobject is null.
Here's the test code I used to verify that it works. So you can test it too. And for learning. It has some stuff that's not necessary for the test. But here it is anyway:
| Code: |
import tango.io.Stdout;
class TestMe
{
this( bool someCondition )
{
if(someCondition)
{
this = null;
return;
}
}
int data = 5;
}
int main(char[][] args)
{
Stdout("Hello universe! It's a new day in Tango land!").newline;
TestMe testMe1 = new TestMe(false);
//Stdout("1 data: ")(testMe1.data).newline;
if( testMe1 is null )
{
Stdout("1 is null. That's wierd. It shouldn't be.").newline;
}
else
{
Stdout("1 wasn't null. as expected.").newline;
Stdout("1 data: ")(testMe1.data).newline;
}
TestMe testMe2 = new TestMe(true);
if( testMe2 is null )
{
Stdout("It works. We've got a null object.").newline;
}
else
{
Stdout("No crap. It doesn't work at all.").newline;
Stdout("2 data: ")(testMe2.data).newline;
}
return 0;
}
|
|
|
| Back to top |
|
|
ShprotX
Joined: 28 Aug 2007
Posts: 24
Location: Ukraine
|
| Posted: Sat Dec 01, 2007 10:15 am Post subject: |
|
|
| satelliittipupu wrote: | | It will just cleanly set the newly created object (this) to be null. So. Instead of asserts and exceptions we should just do that, when the incoming gobject is null. |
It is C-style to return null. D-style is to raise an exception. |
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Sat Dec 01, 2007 5:50 pm Post subject: |
|
|
| ShprotX wrote: | | It is C-style to return null. D-style is to raise an exception. |
You're propably correct. I don't know which would be better. I really just check if(myobject !is null) and I consider that to be valid D.
But.
The current way of raising the exception is
| Code: |
int zero = 0;
zero = zero / zero;
|
I don't see that as D-style in any way. I've really tried all I can to catch that floating point exception. I can't find any documentation how to do it. I think one of the points with an exception is that you can do try{} catch(Exception ex){}. Currently that will just crash your program.
So, if gtkD would to be use exceptions for this, then I think they should be just plain
| Code: | | throw new Exception("Something wrong."); |
And then you can put this into your code:
| Code: |
try
{
GdkPixbuf mypix2 = new GdkPixbuf();
//do something
}
catch( Exception ex )
{
Stdout("Caught it. Yep.").newline;
}
|
I'm just concerned that the current situation should be fixed with something sane. |
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Mon Dec 03, 2007 4:51 pm Post subject: |
|
|
I'm replying to myself, as is usual lately. And mumbling some incomprehensible stuff about some weird details. Excuse me for that. 
Just thought about this some more, and thought that there's two styles that gtkD should follow. The D programming language style - whatever that is. And the GTK+ style, as defined in all the various bindings for other languages.
So, the question here is, what do other bindings do? Do they check for null or throw an exception?
In Java-gnome it's quite difficult to find examples about it, but I found one example of using libglade, which seemed to use exceptions for figuring out if the glade file existed etc. But that's not entirely the same thing, as we're just talking about what to do when the C object is null, and that wouldn't be the case when a glade file would not be found. So, no result for Java-gnome.
In gtk# I found examples which checked if( myGtkObject == null ). It's noticeable that in C# there's also exceptions available, so it seems that it's not throwing an exception, but I can't be sure of that.
In pygtk they seem to check for: if myGtkObject. That's like checking for null as far as I know. I don't know Python, but I think you can't throw exceptions in Python... If that's so, then it of course isn't that great comparison.
In gtkmm I think they check for null, and don't throw exceptions, even that's possible in C++.
I'd say that most of the GTK+ bindings use the checking for null approach or similar. And none that I know of throws exceptions. Correct me if I'm wrong.
I'm just thinking again that gtkD should be as similar as possible to the existing bindings, so that the skill of people already knowing gtk in some other language would not be lost. And the documentation and code examples for other languages would also apply to gtkD. I think that's a good enough reason to use the this = null and if(myGtkObject !is null) approach. |
|
| Back to top |
|
|
Auria
Joined: 29 May 2006
Posts: 44
|
| Posted: Tue Dec 04, 2007 9:44 am Post subject: |
|
|
I personnaly think gtkD should be as D-style as possible. We can already use C bindings to GTK in D (made with BCD) so if we want C-style we can use that... And also, exceptions are nothing new nor hard, they are part of C++ too (only not used widely because too recent addition to the standard)
I don't think we should necessarly try to imitate other bindings |
|
| Back to top |
|
|
ShprotX
Joined: 28 Aug 2007
Posts: 24
Location: Ukraine
|
| Posted: Tue Dec 04, 2007 2:44 pm Post subject: |
|
|
| satelliittipupu wrote: |
I'd say that most of the GTK+ bindings use the checking for null approach or similar. And none that I know of throws exceptions. Correct me if I'm wrong.
I'm just thinking again that gtkD should be as similar as possible to the existing bindings, so that the skill of people already knowing gtk in some other language would not be lost. And the documentation and code examples for other languages would also apply to gtkD. I think that's a good enough reason to use the this = null and if(myGtkObject !is null) approach. |
GTK+ has its own exception handling. When GTK+ raises an exception we must too. When the function returns null, it means that it performs normally but object not found or there's no need in it's creation, etc. So, you've told right things about GTK+ bindings in other languages. Btw, I am familiar with Python and I can tell that it supports exceptions and PyGtk supports them too.
In spite of all that, I still disagree with you proposition to check if the variable is null in the constructor because there will be unnicessary operations: class allocation and initialization. Please, point me a place in the code from where such things are originating. |
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Wed Dec 05, 2007 4:06 am Post subject: |
|
|
| ShprotX wrote: | | GTK+ has its own exception handling. When GTK+ raises an exception we must too. |
Yes. I agree. I think that is not happening at the moment. But I'm not sure, as I haven't looked into it.
| ShprotX wrote: | | In spite of all that, I still disagree with you proposition to check if the variable is null in the constructor because there will be unnicessary operations: class allocation and initialization. Please, point me a place in the code from where such things are originating. |
Hmm. I'm not sure if I understand that correctly.
Do you disagree with the idea of checking C-objects for null inside the D-object constructors? For example in /src/gtk/Button.d (this is from my memory... not the actual code):
| Code: | class Button
{
this(GtkButton* gtkButton)
{
if(gtkButton is null)
{
//do something to inform the user that the creation of her gtkD object
//failed.
}
}
}
|
So, are you suggesting that there was no such checking at all. And if that would be the case, there would be no way for the user to know if the C-object was created or not. (Except checking if( myObject.gtkButtonStruct is null), but that is ugly).
Or are you suggesting that we should throw an exception in that case (if the C-object was null on the D-objects constructor)?
Anyway, it's good that there's some discussion about this, as it will basically set how error checking in gtkD will look like. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
)
