Wątek przeniesiony 2019-06-04 21:37 z przez somekind.

wyjątki kompletnie bez sensu

Odpowiedz Nowy wątek
2019-05-30 10:21
0

Funkcja niezbyt długa, w środku blok try, i sprawdzenie warunku który może często zachodzić, jak tylko user się pomyli.
Jeśli true to leci wyjątek standardowy (znaczy nie jakiejś specjalnej klasy)
W catch parę linijek niżej łapiemy wszytko , zakładamy że jest to powyższy wyjątek i pokazujemy userowi komunikat
Oczywiście prawdziwy wyjątek nie ma szans na sensowną obsługę....
Facepalm
Skoro lameriada nie umie pisać to może niech goto używa na to samo wyjdzie

Ale to pytanie jest, czy bardziej do działu Programistyczne WTF jakie Was spotkały? - Silv 2019-06-04 22:50
A to już wiem po przeczytaniu wątku, zapomnij o moim pytaniu. :) - Silv 2019-06-04 23:24

Pozostało 580 znaków

2019-06-08 01:32
0
jarekr000000 napisał(a):
Gworys napisał(a):

Słowo Optiona albo Ether jest jakoś mało domenowe. :P

I bardzo dobrze.to jest słowo zrozumiałe w kontekście programowania, tak samo jak map, flatmap. Alternatywy gdzie tworzymy business friendly nazwy jak Vernon proponuje (Completes?) to chaos dla programistów.
Jak już muszę mniejsze zło wybrać to wolę, żeby programiści sie w kodzie nie gubili, a biznes gubi się w nim i tak.

Im bardziej ogólnych nazw używasz, tym łatwiej można się zgubić nieważne komu, to typowy mankament języków deklaratywnych. Nie mam nic przeciwko Monadą FlatMapom i etc. ale większość ludzi ma tendencje do pisania bardzo długich łańcuchów funkcji co niekoniecznie jest czytelne.

Mozę nie uwierzysz, ale chodzą na tym świecie takie kwiatki, które uważają, że wyjątki i nulle to efekt zacofania programistycznego a jak się używa optionala to nie ma potrzebny pisać testów, które sprawdzają nulle i wyjątki.

To zupełnie dziwnne co więcej Twoje dalsze wypowiedzi jakby zupełnie idą w innym kierunku.
Tym niemniej - dokładnie: jeśli stosujemy Optionale i Eithery to dlatego, żeby nie testować nulli i wyjątków. Jak ktoś wrzuci do argumentu Optional null ( a nie None) to znaczy, że prosi o NullPointerException i należy prośbę spełnić. Robienie testów na niepoprawny kod IMO jest sensu, zwłaszcza jak daje sietakie kwiatki dość łatwo wykryć.

Nie rozumiesz, Jeśli zachowanie logiki wymaga jakiegoś testowania to dodanie Optionala nie sprawi, że te testy znikną, ponieważ zachowanie funkcji się nie zmienia jedynie implementacja.

Jedynym sensownym dodatkiem w bardziej krytycznych fragmentach kodu będą tu asercje.
(btw. z róznycmi dziwnymi ludźmi miałem do czynienia, ale generalnie wsadzanie nulli w argument Optional lub rzucanie wyjątku jak jest Either to rzadkość, zwykle po pierwszym wyjaśnieniu ludzie ogarniają).

A dlaczego jedynym sensownym.? W kontekście programowania samo sformułowanie "Jedynym sensownym" jakoś mało sensownie brzmi.


Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Exception' not found.

Pozostało 580 znaków

2019-06-08 01:34
2

Tylko że Optional, Either sprawia, że wiesz czego się spodziewać. Bez tego nie wiesz czy jakiś null czy RuntimeException nie wyskoczy zza krzaka.

Optionale itp nie są po to, żeby testów było mniej, tylko po to, żeby kolejne osoby w przyszłości nie nadziały się na jakieś nullowe pułapki


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.
edytowany 1x, ostatnio: danek, 2019-06-08 01:36

Pozostało 580 znaków

2019-06-08 01:40
0
danek napisał(a):

Tylko że Optional, Either sprawia, że wiesz czego się spodziewać. Bez tego nie wiesz czy jakiś null czy RuntimeException nie wyskoczy zza krzaka.

Optionale itp nie są po to, żeby testów było mniej, tylko po to, żeby kolejne osoby w przyszłości nie nadziały się na jakieś nullowe pułapki

Dlatego uważam, że to wspaniały dodatek do programowania obiektowego.

A co do tego RuntimeException to popatrz w moją stopkę.


Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Exception' not found.
Pokaż pozostałe 11 komentarzy
Aha. Rozumiem, że refleksja przydaje się w dość specyficznych sytuacjach? - Silv 2019-06-08 02:02
jak robisz np. biblioteke która na podstawie klasy wygeneruje sqla do bazy danych - danek 2019-06-08 02:04
<idzie poczytać o refleksji> - Silv 2019-06-08 02:05
Nigdy nie widzieliście takiego czegoś jak exeptiony rejestrowane w kontenerze IOC czy tam DI. Na YouTube można o tym prezentacje znaleźć. Tylko trzeba to wpisać po hindusku. - Gworys 2019-06-08 02:07
"jak robisz np. biblioteke która na podstawie klasy wygeneruje sqla do bazy danych" - do takiej rzeczy to raczej makra, a nie refleksja. A nie, czekaj, zapomniałem, że to C#. - Krolik 2019-06-09 18:37

Pozostało 580 znaków

2019-06-17 10:26
0
danek napisał(a):

Tylko że Optional, Either sprawia, że wiesz czego się spodziewać. Bez tego nie wiesz czy jakiś null czy RuntimeException nie wyskoczy zza krzaka.

IMO bardzo słaby argument. Checked exception w Javie też sprawiają, że wiesz czego się spodziewać i jakoś nikt ich nie chwali.
Ogólnie całe pure functional jest fajne, ale do pewnego momentu o czym puryści zapominają. Aplikacje w prawdziwym świecie zależą od stanów. Ot taki prosty przypadek, insert do bazy danych - proszę zaprojektować funkcję, która niezależnie od stanu bazy danych będzie zwracała to samo. Ewentualnie jej bezbazodanowy odpowiednik, z replikacją i trwałością.
Oczywiście można potraktować bazę danych jako argument i wtedy w teorii dałoby się coś takiego zrobić. Ale wtedy zaraz trzeba będzie dorzucić całą gamę innych rzeczy, typu kontekst użytkownika/security, jakiekolwiek inne usługi zewnętrzne itp.

Co rozumiesz przez "stan bazy danych"? - Silv 2019-06-17 14:28

Pozostało 580 znaków

2019-06-17 10:34
1

Aplikacje w prawdziwym świecie zależą od stanów.

W jaki sposób FP przeszkadza w stanowości?

proszę zaprojektować funkcję, która niezależnie od stanu bazy danych będzie zwracała to samo.

Proszę - funkcja, która niezależnie od stanu bazy danych zwraca to samo, w Rust (sam język nie jest czysto funkcyjny, lecz przytoczony przeze mnie poniżej kod już tak):

fn random() -> usize {
  4 // chosen by fair dice roll
}

Jeśli szukasz rzeczywistych przykładów kodu FP, który odwołuje się do baz danych, wpisz w Google haskell database tutorial ;-)

Oczywiście można potraktować bazę danych jako argument i wtedy w teorii dałoby się coś takiego zrobić

W OOP wrzuciłbyś bazę danych jako zależność przez DI - niczym nie różni się to od przekazywania jej bezpośrednio do funkcji przez argument.

Ale wtedy zaraz trzeba będzie dorzucić całą gamę innych rzeczy, typu kontekst użytkownika/security, jakiekolwiek inne usługi zewnętrzne itp.

W jaki sposób FP to uniemożliwia?


edytowany 7x, ostatnio: Patryk27, 2019-06-17 10:43
"chosen by a fair dice roll", zdaje mi się. - Silv 2019-06-17 14:30
@Patryk27: OK. ;) Ale nadal. - Silv 2019-06-17 15:21

Pozostało 580 znaków

2019-06-17 11:33
0
wartek01 napisał(a):

IMO bardzo słaby argument. Checked exception w Javie też sprawiają, że wiesz czego się spodziewać i jakoś nikt ich nie chwali.

Są pewne różnice jak np: dodając nowy wyjątek, musisz go obsłużyć, dodając nowy typ błądu w Either zazwyczaj używasz jakiegoś enum i nie musisz nigdzie więcej nic zmieniać


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.
zgadzam się z tym, że są różnice, ja tylko odniosłem się do tego konkretnego argumentu - wartek01 2019-06-17 16:57

Pozostało 580 znaków

2019-06-17 11:43
1

proszę zaprojektować funkcję, która niezależnie od stanu bazy danych będzie zwracała to samo. Ewentualnie jej bezbazodanowy odpowiednik, z replikacją i trwałością

A proszę bardzo, przykład w Eliksirze:

defmodule State do
  def start_link(state), do: spawn_link(__MODULE__, :run, [state])

  def get(pid) do
    ref = make_ref()
    send(pid, {:get, ref, self()})

    receive do
      {^ref, data} -> data
    end
  end

  def set(pid, state), do: send(pid, {:set, state})

  def run(state) do
    receive do
      {:get, ref, pid} ->
        send(pid, {ref, state})
        run(state)
      {:set, new_state} ->
        run(new_state)
    end
  end
end

Masz moduł, który przechowuje stan, a mimo tego nie ma w nim nic mutowalnego.

przecież to nie jest w żaden sposób persistent. Znam pattern State i wiem, że można go zrobić jako niemutowalny. - wartek01 2019-06-17 16:58

Pozostało 580 znaków

2019-06-17 17:12
1
Patryk27 napisał(a):

W jaki sposób FP przeszkadza w stanowości?

Dla mnie w żadnym, ale tutaj była mowa o niewinności funkcji, czyli cytując:

Niewinność: brak (bezpośrednich) interakcji ze światem lub wewnętrznym stanem programu (inculpable)

W OOP wrzuciłbyś bazę danych jako zależność przez DI - niczym nie różni się to od przekazywania jej bezpośrednio do funkcji przez argument.

Tak, ale - uwaga - dlaczego nie przekazuje się tego przez argument? Sprawa jest prosta, bo wstrzyknięcie zależności jako konstruktor jest (w granicach rozsądku) jest bardziej czytelne, niż przekazywanie tego przez argument.

I tutaj dochodzimy do tego, co moim zdaniem najważniejsze - trzymanie się kilku dogmatów opisanych przez @Kamil Żabiński skończy się na tym, że dostaniesz jedną mega funkcję, której składowe części faktycznie będą niemutowalne, ale będą miały kilkadziesiąt argumentów - kilka na bazy danych, inne na jakieś kolejki, inne jeszcze na jakieś zależności zewnętrzne itp. - i przez to będą nieczytelne. A pisząc w językach programowania - zwłaszcza jeśli się pisze wysokopoziomowo - bardzo ważna jest czytelność kodu.

Ale wtedy zaraz trzeba będzie dorzucić całą gamę innych rzeczy, typu kontekst użytkownika/security, jakiekolwiek inne usługi zewnętrzne itp.

W jaki sposób FP to uniemożliwia?

Nie piszę, że uniemożliwia. Po prostu taki kod będzie trudno czytelny, bo za każdym razem będziesz musiał przekazywać te N argumentów.

Pozostało 580 znaków

2019-06-17 20:24
1

Po prostu taki kod będzie trudno czytelny, bo za każdym razem będziesz musiał przekazywać te N argumentów.

Ale o tym, że w FP istnieją struktury, to ty wiedz. Więc możesz mieć jedną strukturę tworzoną na starcie zawierającą wszystkie opcje potrzebne do działania programu i zwyczajnie "przepychasz" ją w dół.

Już to było przerabiane, działa źle: https://en.wikipedia.org/wiki/God_object - wartek01 2019-06-17 20:54
@wartek01: niby tak, ale nie do końca. Definicja God object to struktura, która "knows too much or does too much", natomiast state (czy inaczej jak to nazwiesz) nie wie co składuje, ona tylko składuje. Zobacz sobie jak działa React czy Elm gdzie używa się właśnie takiej struktury. - hauleth 2019-06-17 23:06
Bawisz się w jakieś zabawy słowne. Jeśli do wszystkich funkcji przekazujesz obiekt, który pozwala na dostęp do bazy danych to baza danych jest dostępna w każdej funkcji i tyle, masz god object. Wszystko ma dostęp do wszystkiego, a wchodząc w funkcję nie musisz wcale zobaczyć z czego funkcja korzysta. I w sumie React to fajny przykład na to jak łamanie dogmatów jest wygodne dla programistów bo nagle okazuje się, że każda funkcja jest zależna od zewnętrznego stanu. - wartek01 2019-06-18 07:30

Pozostało 580 znaków

2019-06-18 07:59
1

Dla mnie w żadnym, ale tutaj była mowa o niewinności funkcji, czyli cytując:

Raz jeszcze: w jaki sposób ta definicja kłóci się ze stanowością (Aplikacje w prawdziwym świecie zależą od stanów)?

Mówi ona jedynie tyle, że od czapy nie możesz sobie zmodyfikować wewnętrznego stanu programu, co powinno być przestrzegane nawet w językach imperatywnych, skoro zależy CI na czytelności kodu.

wstrzyknięcie zależności jako konstruktor jest (w granicach rozsądku) jest bardziej czytelne, niż przekazywanie tego przez argument.

Brzmi subiektywnie, więc IMO nie ma co wchodzić w ten temat - coś w stylu taby > spacje itd.

będą miały kilkadziesiąt argumentów - (...) - i przez to będą nieczytelne

No tak, bo gdy wstrzykniesz dwadzieścia serwisów przez konstruktor w OOP to otrzymasz wyjątkowo czytelną i łatwą w utrzymaniu klasę ;-]


Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0