pancake wrote: > I've been thinking a bit on this post.. and I agree with it that > exception handling via try/catch hides the proper control flow of > the program and can result in problematic situations. > > https://groups.google.com/forum/#!topic/nodejs/1ESsssIxrUU/discussion > > as far as GObject follows a proper approach, and Vala just adds some > sugar on top of it, we could add a way to manager exceptions in a > more specific way. but I don't know which would be the right way to > do it. > > I just want to share this thing with you and get some feedback about > what you think it's ok for a language that aims to avoid common > programming errors and keep the code easier for maintainance.
If a method returns an error code return value (instead of an exception), to ignore it you just need to OMIT some code, i.e. it is not immediately obvious that the error return was dropped. With try/catch and exception propagation strictly checked by the compiler, to ignore an error you have to add some very obvious code catching the exception and doing nothing with it, i.e. you need to make an effort to ignore it. Otherwise the compiler complains and forces you to declare the exception as thrown by the method. Strict checked exception handling seems much safer to me. I guess JavaScript is completely non-strict, which means there is no benefit to having exceptions because the compiler can't give any warnings or errors. According to the docs, Vala is strict but only gives compile warnings, but this is good enough if you act on them. Essentially exceptions and error returns are the same, the only difference is the syntax and the checking done by the compiler. A syntax that makes coding omissions more obvious seems better to me, even if it is a little more verbose. (If libraries are badly designed and throw exceptions when they shouldn't, that is another question, though.) Talking about strictness, in general, I have found Vala not strict enough, and I think this non-strictness is inherited from GLib. Often the generated code detects a fatal condition (e.g. NULL pointer) and then just carries on or returns. This usually means a crash much later on in some unrelated code. I would prefer a crash right away, because it is obviously something not planned for, so the program behaviour is undefined from then on (e.g. maybe I was counting on that routine to initialise variables required later on, or to get a lock, so loads of subtle errors could appear as a result -- and I've actually had to debug several cases like this.) This non-strictness just means more time spend debugging and cursing Vala! It depends on how resilient you want the code to be. Java is not perfect either: it really needs the '?' type flag like Vala has to eliminate null-pointer-dereference errors at compile time rather than run time, for example. (I know it is not fully checked in Vala yet, though.) (There are two approaches to unplanned-for conditions: muddle on through, potentially breaking design assumptions made by the programmer, and leave bugs lurking for later, or fail immediately and get the bug fixed. Over several large projects I've learned that if you're aiming for a solid bug-free application, the second approach is the only way. If you want a middle-quality application, then muddling through may be okay, I guess. Failing immediately means the bug gets fixed quickly, and also means that testing is more worthwhile because the bugs show up more easily. To do this means a little bit of discipline, but Java helps more than Vala in this case.) To me, having syntax and compiler checks that make it harder to make coding errors is helpful because that means a lot less time spent debugging. If you want to use Vala as a scripting language (quick to code, little discipline, few checks), I think that is supported because uncaught exceptions generate compiler warnings instead of errors. Jim -- Jim Peters (_)/=\~/_(_) j...@uazu.net (_) /=\ ~/_ (_) UazĂș (_) /=\ ~/_ (_) http:// in Peru (_) ____ /=\ ____ ~/_ ____ (_) uazu.net _______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list