Ozyrys napisał:
jak zniwelować błąd jak ma np kod:
var y:Integer;
begin
y:=StrToInt(InputBox('Y','Y',''));
sg.Cells[1,y]:=Inputbox('TEKST','TEXT','');
i ktoś mi wpisze tekst to jak zrobić żeby zamiast tego standartowego błędu wyskoczył mi mój showmessage('Tu ma być zmienna Y a nie tekst'); //?????
Poczytaj o Try...Finally i Try..Except
//I nie kasuj posta....zglos sie z tym do ktoregos z moderatorow..mL
Poczytaj o Try...Finally i Try..Except
Dzieki szymek dopiero sie ucze i nie o wszystkim pamietam!
A po co.. nie lepiej skorzystać z CASE i funkcji ORD... wtedy mamy pewność, że user wpisze to co ma wpisać.
Nie, bo tak prościej jest.
No właśnie, ja jako czlowiek starej daty mam wewnętrzny opór przed try...except. Wyjątek (nawet obsłużony), do dla mnie jak błąd i wolę sprawdzić 'przed', czy zastosować np. StrToIntDef i sprawdzić if-em. Dopiero niedawno popełniłem fragment programu, w którym obficie stosowałem try..except, a nawet raise - bo było bardzo trudno przewidzieć wszystkie niepoprawne wartości wejściowe, a dokładniej, oprogramowanie szczegółowego sprawdzania wszystkich możliwości doprowadziłoby mnie do odcisków na opuszkach palców.
Ciekaw jestem, czy ktoś się orientuje dokładnie, jak ta sprawa wygląda z punktu widzenia wydajności. Myśląc o tym teraz doszedłem do wniosku, że metoda "tradycyjna" (ze sprawdzaniem) może byc gorsza, bo traci czas na sprawdzanie czasem wielu warunków za kazżdym razem. Zaś obsługa wyjatków to kod szybki bo nie sprawdzający jawnie poprawności danych. Tzn sprawdza je procedura (np) StrToInt, aby w wypadku błędu podnieść wyjątek. Jeśli ja sprawdzam sam dane przed wstawieniem ich do StrToInt, to są one chyba sprawdzane dwukrotnie - przeze mnie i przez StrToInt!!!
Czy powinienem zmienić zwyczaje??? Czekam na wasze przemyślenia.
Dokładnie to miałem na myśli. Sprawdzając warunki przez IF lub CASE, jak kto woli, mamy pewność, że błąd który wyniknie jest spowodowany złymi danymi wejściowymi, a nie czym innym. TRY itd.. jak dla mnie jest zbyt ogólne... bawet nie rozumiem zbyt tego - błąd moze byc nawet w kodzie, i przez TRY, wszystko sie wali. Dzieki sprawdzeniu warunku jak napisałem, mamy większą władze nad kodem i całym programem - łatwiej dochodzić do błędów i w ogóle. Też nie używam nigdy TRY itd...