| View previous topic :: View next topic |
| Which error handling mechanism should be implemented in gtkD? |
| GTK+ style null-references. |
|
9% |
[ 1 ] |
| D style exceptions. |
|
54% |
[ 6 ] |
| Exceptions for explicit client side calls to constructors. Null-references everywhere else. |
|
0% |
[ 0 ] |
| Null-references + optional error handling routine as additional function parameter. |
|
0% |
[ 0 ] |
| Runtime selection of error handling mechanism (null-references, exceptions, custom handlers). |
|
36% |
[ 4 ] |
|
| Total Votes : 11 |
|
| Author |
Message |
Pse
Joined: 13 Dec 2007
Posts: 36
|
 Posted: Sat Dec 22, 2007 4:54 pm Post subject: Error handling |
 |
|
I'm sure you're all aware of the discussion about gtkD's error handling mechanism. If not, you may refer to the 'asserts are useless' thread and ticket #3.
Given this is a major design decision that will affect the way gtkD works and the way apps are developed with it, it's been agreed it's in the best interest of the project to let the community decide.
The poll should display every option discussed so far. If you feel any necessary options are missing, please make a post about it and the poll will be restarted.
The sooner this decision is made, the sooner we'll get gtkD back on track.
The poll will run until a proper trend can be determined.
You may discuss the options below.
Last edited by Pse on Sat Dec 22, 2007 6:00 pm; edited 2 times in total |
|
| Back to top |
|
 |
Pse
Joined: 13 Dec 2007
Posts: 36
|
| Posted: Sat Dec 22, 2007 5:57 pm Post subject: |
|
|
I have picked D style exceptions. However, I should point out that there are two very good reasons this is not done in other bindings of GTK+.
* GTK+ checks on its own most of the pointers it gets (though we've all had our fair share of segmentation faults using it). It's usually redundant to check for them in the wrapper.
* The GTK+ philosophy of checking for errors implies a distinction between catchable errors and programming errors. The way GTK+ is designed, programming errors get reported with g_error(), g_assert(), etc.; while catchable errors are reported by return values or GError objects. According to the GTK+ documentation, GError is akin to exceptions in those languages that support them. Therefore, as exceptions are already implemented in the form of GError objects, it's usually redundant to implement them using the language's native constructs.
However, in spite of these two very good reasons, I think exceptions will give gtkD an edge over GTK+'s way of handling errors (at the cost of additional null pointer checks).
* Exceptions, being a language construct, imply a clear distinction between exception handling code and non-exception handling code. The programmer is provided with a better visual description of the paths the program follows in each condition.
* Exceptions enforce better programming practices. Either you catch the exception and place the proper constructs in place, or you are completely, absolutely sure they won't happen. The programmer is compelled to check for any abnormal conditions if he or she wants the program to continue running. No more unchecked objects that may become a liability in the future. And if they do, you'll either get the condition caught and properly handled, or the exception will pass through and you will get informed about it.
* Exceptions allow for batch construction and check of objects in one pass, without resorting to C style potentially confusing pointer checks such as these:
| Code: | | if(!(a && b && c && d && e)) printf("Some object is null."); |
Instead, D style checking:
| Code: | try{ /* Calls to constructors */ }
catch(ConstructionFailure e){ printf("Some object is null."); }
catch(NullGObjectFromGTK){ printf("Some GTK call failed."); }
catch(){ printf("Wow, something went wrong and was not expected."); } |
It's completely clear and easy to read.
* "What if I really want to know whether an object is in place, do I really need to place a proper 'catch' construct? It's just polluting my code!"
Yes, you need to do so, and it's not bad. It's readable and perfectly tolerable if you do it the right way. Just put the block of code in question inside a try block and be done with it; you should do it anyway. Put the catch block at the bottom. Alternatively, if it's really only ONE thing you don't care about checking, do it this way:
| Code: | try SomeFunctionThatThrowsOnNulls();
catch(ConstructionFailure){ } |
Not only is it clear that you don't care specifically about the construction failure, but if any other error conditions happen, they will still pass through and inform of the failure! Should an unexpected condition arise, it'll be much easier to find the relevant piece of code! If it's a NullGObjectFromGTK exception that passed through, then you will know it cannot be from the previous example. Instead, it has to be from this last one (or whatever doesn't handle such exceptions), you just need to grep for the relevant code. Imagine what could be done if reflection and/or introspection were in place.
* Lastly, just a tiny example:
| Code: |
Widget a,b,c,d,e,f;
try
{
a = new Button();
b = new Button();
c = new Label();
d = new Label();
e = new CheckButton();
f = new Entry();
}
catch(){ /* Exception handling code goes here. */ }
/* Do stuff! I perfectly *know* each and every one of the widgets above is not null. And I can clearly *see* that in the code.*/ |
I think, however, that any of the options in the poll are better than what's currently implemented in gtkD. Whatever the result, I'll be happy to see it implemented instead  . |
|
| Back to top |
|
|
Pse
Joined: 13 Dec 2007
Posts: 36
|
| Posted: Sat Dec 29, 2007 7:09 pm Post subject: |
|
|
Kaarna's suggestion is now implemented and enabled by default in r348.
Version "Exceptions" is now also available with preliminary support for exceptions inside constructors. This is in no way final, and should be treated accordingly (i.e. don't write important code based on it).
Version "NoAssert" is now not available anymore, so code using it should be updated.
Please report any bugs to ticket #3. |
|
| Back to top |
|
|
kaarna
Joined: 03 Apr 2006
Posts: 92
Location: Finland
|
| Posted: Tue Jan 01, 2008 4:07 pm Post subject: |
|
|
I think exceptions are ok anyway. It just has to be done in a way that it works...
The null thing will work as a mean time solution... (can you say it like this in english...)
I thought that the version of selecting the error handling mechanism in runtime might be bad, as that will effectively make many different kinds of code that will all be called gtkD, but they won't be working with each other. The API will not be clearly defined, if there are switches that suddenly change the behaviour of the whole API. For the sake of easy sharing of code between code examples, and different projects, it would be better to have only one error handling mechanism. And it seems that I'm now persuaded to believe it could be exceptions... Their clear benefit is that you can have lots of information about an error passed with the exception, and the exception type will already tell alot about what happened. |
|
| Back to top |
|
|
Pse
Joined: 13 Dec 2007
Posts: 36
|
| Posted: Tue Jan 01, 2008 5:11 pm Post subject: |
|
|
I think so as well. However, given the yet inconclusive results of the poll, I decided to implement option a) as a default for now (i.e. null references), which is what is now available in SVN. Version "Exceptions" is just a placeholder till a proper decision is made, and serves the purpose of letting us test exceptions in the meantime. Of course, once that decision is made, either version "Exceptions" will go away, or it'll become the default (and I'd like to emphasize that: there will be NO 'versions' to select the error handling mechanism in the final code, current code is just preliminary and serves the purpose of letting us test either case till a proper decision is made).
The inconclusive results of the poll are also the reason why proper subclassed exceptions haven't been implemented yet.
I'd like to add that option e) (runtime selection) is actually hard to implement safely and properly, which is why I think either option a) or option b) are the way to go. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Tue Jan 01, 2008 5:50 pm Post subject: |
|
|
Maybe I don't understand the currently tested exception scheme; but, from what I see, all that's being tested is if a null object is being passed to a constructor in which case a null is either assigned to this or and an exception is thrown. What does that achieve other than a very specific situation of gtkd classes being isntantiated with null objects?
Currently there is no exception mechanism integrated for the situation where a gtk_* call fails... right now, all that happens in a gtkd class is that the underlying gtk function returns the result of the call which is forwarded in the return of the class method (meaning poll option #1 is already implemented by default). This is completely C oriented and dependent on the underlying error convention of gtk (not sure, but maybe a call can be made to gtk_error for specifics on the error? Or maybe GtkD class glib/ErrorG is put to use?).
What this seems to mean is that the current solution is not even touching the surface of the real issue... or maybe I'm not understanding what's going on. The null in constructor is really unrelated to gtk_* function error handling. The work involved in converting gtk_* errors to D exceptions does not appear to be a trivial one.
Incidentally, I voted for D exceptions, but apparently I didn't understand the problem completely.
Correct me if I'm wrong.
-JJR |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Tue Jan 01, 2008 8:24 pm Post subject: |
|
|
| Bah... obviously I missed the whole point. Disregard my post. The whole point is that all gtkd objects created are passed to other gtkd objects via the constructor... so obviously that's where we catch the nulls returned from the internal gtk functions. |
|
| Back to top |
|
|
Pse
Joined: 13 Dec 2007
Posts: 36
|
| Posted: Tue Jan 01, 2008 9:21 pm Post subject: |
|
|
| Quote: | | Currently there is no exception mechanism integrated for the situation where a gtk_* call fails |
Since r348 untyped exceptions are available for all gtk calls that construct an object. Since r360 untyped exceptions are available for all gtk calls that return an object. Changes in r360 are not in-code yet, but will be in the next full wrap. I don't recommend enabling exceptions until proper subclassing for each kind of exception is in place.
| JJR wrote: | | Bah... obviously I missed the whole point. Disregard my post. The whole point is that all gtkd objects created are passed to other gtkd objects via the constructor... so obviously that's where we catch the nulls returned from the internal gtk functions. |
I'll try to elaborate a bit. Right now, exceptions don't give us anything over plain old GTK+ style null-references. Eventually, however, they could do some good. Right now, there are two types (in fact, three, because there are some old, forgotten exceptions in some obscure module) of exceptions in place: exceptions raised by failure to construct an object, and exceptions raised by null return values from 'get' methods. These are the two exceptions I described in my long post above (ConstructionFailure and NullGObjectFromGTK). Of course, these two are not typed yet, but eventually will be, so things like those described in that post will be possible.
Basicly, the one big advantage of exceptions is enforcement of better programming practices. Another big advantage is the reduction of the number of dumb, difficult-to-trace mistakes (such as dereferencing a null pointrer). You can actually see that right now in SVN by compiling that gtk/DrawRect demo from ticket #12. Without exceptions, that is, the default behaviour, you'll run it and get a big nice segfault. With "version=Exceptions", you'll actually get an error printed to the console that reads "Null <type> passed to object constructor", and the program ends (this is good, there's no way the program can continue without catching this exception, and in fact, it is that that allows it to stop before segfaulting due to the dereference that follows).
And yet another advantage is the clear distinction between handlers that work on different types of exceptions. If you don't care about one exception, you just disable that error, which means any other uncaught errors will still pass (this is good!).
Exceptions, for gtkD, do come with one big disadvantage: additional null pointer checks. Because of the way GTK+ is designed, there's no way we can work around that, and that means that, yes, every call to GTK+ that returns an object is checked. We could probably implement an alternative method for important calls, so that those who need the best performance can use them (at the expense of dealing themselves with the return values from GTK+ functions). |
|
| Back to top |
|
|
Mike Wey
Joined: 07 May 2007
Posts: 428
|
| Posted: Wed Feb 20, 2008 4:46 pm Post subject: |
|
|
| Pse wrote: | | Since r348 untyped exceptions are available for all gtk calls that construct an object. Since r360 untyped exceptions are available for all gtk calls that return an object. Changes in r360 are not in-code yet, but will be in the next full wrap. I don't recommend enabling exceptions until proper subclassing for each kind of exception is in place. |
r411 adds the changes from r360 to the code with a full rewrap.
Has anybody thought about an end date for this poll?
How about March 31st, by that date the poll has been running for a little more than 3 months? |
|
| Back to top |
|
|
Pse
Joined: 13 Dec 2007
Posts: 36
|
| Posted: Sun Mar 30, 2008 6:25 pm Post subject: |
|
|
Hi, I've been out of the loop for awhile, but I thought I might comment on this since I started the poll after all. I think the results are non-conclusive. There are less than 20 votes, and almost all are divided between two options. I think it may be wise to implement whatever is easier to maintain for the time being. Exceptions are nice, but there are many subtle considerations that have to be taken into account to achieve a proper design and implementation. For now, exceptions should only be raised whenever it is sensible to do so. Looking at other implementations (such as PyGTK) might help in this area. NULLs should be returned whenever GTK+ does for the time being.
IMO, the poll can be considered closed. |
|
| 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
