If there aren't any situations where ';' goes after '}', such
situations should probably not be introduced. Syntax should be
consistent. nocatch{} is then probably better than try{};, but I still
like code attributes solution the most. The feature of pointing out
exceptions that should be ignored is IMO pure code-generation thing,
you don't change any logic by using nocatch {} instead of just ignoring
the exception handling, you change only the generated code.

best regards,

>Maybe 
>
>  nocatch { ... }
>
>would make that case even clearer.
>
>Am Dienstag, den 01.11.2011, 00:43 +0100 schrieb rastersoft:
>> I don't think that
>> 
>>      try { ... }
>> 
>> is a good idea, but
>> 
>>      try { ... };
>> 
>> is. Just removing the catch can result in involuntary errors, but if you 
>> have to choose between a ";" or a "catch", the probability of 
>> "forgetting" it is greatly reduced.
>> 
>> El 31/10/11 23:22, pancake escribió:
>> > Hi
>> >
>> > On 31/10/2011, at 20:16, Aleksander Wabik<[email protected]>  wrote:
>> >
>> >> My 2 pennies:
>> >>
>> >>> What about adding a code attribute like [IgnoreException] ? that would 
>> >>> perform better than trycatching
>> >> It seems the most logical option to me. Vala is a language that allows
>> >> ignoring exceptions, and (as far as I remember, it was a while ago when
>> >> I was writing my vala code) it generates code printing warning about
>> >> uncaught exception each time the exception is thrown, but not caught. I
>> >> guess that we should have two solutions (not one or the other, but both
>> >> implemented):
>> >> - command line switch like -Wno-exceptions - it would disable all
>> >>   warnings about uncaught exceptions at the compile time, and in the
>> >>   non-debug builds it would also cause not generating code for printing
>> >>   exception information if the exception is thrown;
>> > Looks an ugly solution to me. Some of those exceptions are important :)
>> >
>> >> - and some code attribute, that could be used in code, if the author is
>> >>   100% sure that in this particular case exception will never be
>> >>   thrown, or that it can be ignored (compile and run time behaviour the
>> >>   same as above).
>> >>
>> > The option of allowing syntax like
>> >
>> > Try { ... }
>> >
>> > Without catch looks good to me, and probably cleaner than adding a code 
>> > attribute.
>> >
>> > But i dont know of any lang that does this already.. So maybe its 
>> > inconsistent
>> >
>> >
>> >> Both these features have the advantage that no syntax changes in the
>> >> language are needed.
>> >>
>> >> best regards,
>> >>
>> >>> On 31/10/2011, at 10:06, Xavier Bestel<[email protected]>  wrote:
>> >>>
>> >>>> On Sun, 2011-10-30 at 11:04 -0400, Sam Wilson wrote:
>> >>>>> Perhaps a better way to do this is like this:
>> >>>>>
>> >>>>> string[] test = new string[3];
>> >>>>> for (int i = 0; i<  3; i++)
>> >>>>> {
>> >>>>>     try
>> >>>>>     {
>> >>>>>         test[i] = kf.get_string(group, key);
>> >>>>>     }
>> >>>>>     catch (KeyFile.Error error)
>> >>>>>     {
>> >>>>>         // Do nothing
>> >>>>>     }
>> >>>>> }
>> >>>>> if (!test[0]&&  !test[1]&&  !test[3]) return false;
>> >>>>>
>> >>>>> What do you think?
>> >>>> Won't that interrupt the execution flow, i.e. if the first
>> >>>> g_key_file_get_string() throws an exception, the other ones won't be
>> >>>> executed ?
>> >>>>
>> >>>>    Xav
>> >>>>
>> >>>> _______________________________________________
>> >>>> vala-list mailing list
>> >>>> [email protected]
>> >>>> http://mail.gnome.org/mailman/listinfo/vala-list
>> >>>>
>> >>> _______________________________________________
>> >>> vala-list mailing list
>> >>> [email protected]
>> >>> http://mail.gnome.org/mailman/listinfo/vala-list
>> >>
>> >> -- 
>> >> Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na
>> >> serwerze hkp://keys.gnupg.net
>> >>
>> >> My public key with signature 1024D/E12C5A4C is on the server
>> >> hkp://keys.gnupg.net
>> > _______________________________________________
>> > vala-list mailing list
>> > [email protected]
>> > http://mail.gnome.org/mailman/listinfo/vala-list
>> 
>
>
>_______________________________________________
>vala-list mailing list
>[email protected]
>http://mail.gnome.org/mailman/listinfo/vala-list


-- 
Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na
serwerze hkp://keys.gnupg.net

My public key with signature 1024D/E12C5A4C is on the server
hkp://keys.gnupg.net

Attachment: signature.asc
Description: PGP signature

_______________________________________________
vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to