Situatii... exceptionale

MarianG, on 13 septembrie 2017 - 14:51, said:

Iar principala grija a devului este sa-i ofere userului suport tehnic necsar si reolvarea problemei in cel mai scurt timp posibil , de aceea are nevoie de
stacktrace.
In plus in cazul de fata tind sa cred ca avem de a face cu o  un server care genereaza  astfel de mesaje si un client de java, In acest caz
daca serverul arunca o erare de tip Runtime, avand stacktrace-ul la dispozitie (care are si alte erori) poti sa-ti dai seama de unde vine eroarea de runtime si daca cumva
vine si din alte pluginuri externe ale serverului facute de altii. Daca tu nu poti identifica eroarea , dai tot stacktrace-ul devului care a facut serverul si in 10 minute ai  solutia de fix, pt ca stacktraceul verbose il ajuta enorm pe dev sa-ti indice solutia corecta.

Quote

Se poate sa nu fie si 3rd party daca aceste tool-uri sunt incluse  ca framwork de audit., care este inclus in aplicatia, dara asta doar daca vrea clientul.
Pt dev inseamna mutarea auditului din afara in interiorul aplicaitie.

Oricum prefer tot stacktraceul decat  o eroare chioara de genul  : Apllication hang due to 0x00E3320C2

_Smiley_, on 13 septembrie 2017 - 15:17, said:

Reformuleaza ca nu am inteles .Cum adica erorile care sa ascunda alta erori(vorbim de java aici si de stacktrace-ul unei aplicatii java server)

Nu inteleg cum sa ascunda o  eroare pe alta din moment ce stacktrace spune : Caused by ... si apoi ofera error-chainul de la origine pana la destinatie.

Edited by Qupidqu, 13 September 2017 - 15:45.

exceptiile nu se folosesc pt logare de informatii, ci pt situatii exceptionale ca de aia se cheama asa. erori sau situatii corupte care impedica o functionalitate sa ruleze corect.
daca un dev foloseste exceptii inseamna ca ceva nu e in ordine si executia ar trebui oprita cu rollback, logare etc iar clientul sa stie in ce stare a ramas, ideal ca si cum acea funcionalitate nu a rulat.
daca totul e in ordine dar se folosesc exceptii pt logare atunci exceptiile sunt folosite aiurea, trace-urile te incurca.

andreim77, on 13 septembrie 2017 - 15:44, said:

Primo:
Dar cine foloseste exceptiile pt logare de informatii ?
In plus si o exceptie este o  informatie in sine.

Secundo:
daca am exceptii proprii care afiseaza si informatii despre cum sa rezolve acea exceptie sau
informatii aditionale importante care insosesc exceptiile ?

In plus cred ca vorbim despre un java server de tipul:
Apache Tomcat/Jetty/WebLogic/Glassfish/Wildfly si cred ca acele mesaje multe i le spune atunci cand face deploy la aplicatie pe server.
Daca este asa pai este normal sa fac parcursul aplicatiei pe server. si etapele de deployment

Edited by Qupidqu, 13 September 2017 - 15:56.

cine foloseste exceptii unde nu e cazul.

Qupidqu, on 13 septembrie 2017 - 15:47, said:

aparent tu, din moment ce consideri ca log-ul si stacktrace-ul sunt acelasi lucru

Qupidqu, on 13 septembrie 2017 - 12:49, said:

Edited by MarianG, 13 September 2017 - 15:54.

MarianG, on 13 septembrie 2017 - 15:54, said:

aparent, si aparent si toti developerii de servere java.
Logul inglobeaza si stacktraceul. IN JAVA nu exista separatie intre logul serverului  si stacktrace.Totul este in logul serverului.

deci logul inglobeaza stacktrace-ul.
deci nu sunt egale nici macar conform intelegerii tale.
ma exact niste text care iti arata lantul de apeluri din functia x pana la main e scris in log.

Edited by andreim77, 13 September 2017 - 16:01.

la aplicatiie precum servere  de java logul are si stacktraceul, pt ca logul arata comportamentul aplicaitiei pe server.

Edited by MarianG, 13 September 2017 - 16:05.
removed quote

bine, revenind la problema initiala, ce rol are logul pt un client daca totul merge bine?
adica implicit, verbozitatea ar trebui sa fie zero.
prin client se intelege orice/oricine foloseste super codul respectiv.

Qupidqu, on 13 septembrie 2017 - 15:47, said:

vorbim despre o aplicatie care functioneaza si arunca stack-trace, restul sunt necunoscute

andreim77, on 13 septembrie 2017 - 16:06, said:

Nu chiar. Daca aplicatia este un server java atunci acel log verbose iti ofera statusul aplicatiei tale pe server.Ce face aplicatia ta pe server, ce resurse acceseaza si daca intalneste erori , bum apare stacktrace la  accesarea unei resuse pe server, etc

De exemplu cei care creaza servere in java se asteapta ca acel user sa nu aiba probleme in a  intelege un stacktrace si de a fi obsinuit cu logul verbiose, adica nicdidecum
un log obisnuit.

iar in cazul de fatza cred ca avem de a face cu un server java in cara  initiatorul a facut deploy la o aplicatie pe server si a inceput serverul sa-i arunce informatii dar si unele erori
insa care nu afectau executia de baza a aplicatiei caci erau informatii ale serverului..

MarianG, on 13 septembrie 2017 - 16:12, said:

Este normal sa faca asa daca aplicatia este server de java  pe care se face deployment la o alta aplicatie de java.
Este chiar binevenit stacktrace-uri in astfel de situatii.

Cui ?

Celui care face deployment la aplicatie pe serverul java si  apoi urmareste cum evolueaza pe server, aplicatia sa,
adica dev-ului

Edited by MarianG, 13 September 2017 - 19:06.
quote

Qupidqu, on 13 septembrie 2017 - 15:25, said:

adica un utilizator obisnuit sa vada 20 de erori la pornirea aplicatiei nu va observa ca sunt de fapt 21 si ca una din ele chiar e importanta.
sa dai prea multe informatii unui utilizator e la fel de nociv ca atunci cand nu dai deloc. o aplicatie nu ar trebui sa afiseze, in mod normal, decat erori care impiedica buna ei functionare.

Qupidqu, on 13 septembrie 2017 - 16:13, said:

daca nu afecteaza corectitudinea aplicatiei care e rostul erorilor pt client? imi pare ca au pierdut toti timp, si cei care au implementat erorile inutile, si timpul de rulare e afectat pt generarea si logarea erorilor inutile si clientul se uita chioras la ele si nu stie, a mers sau n-a mers?

_Smiley_, on 13 septembrie 2017 - 16:57, said:

Stai putin ca nu intelegi o chestie importanta.Majoritatea aplicatiilor java (99%) sunt aplicatii JAVA EE de server.
Iin acest context ,avem urmatoaterele :
1)utilizatorul de rand nici macar nu exista doarece el interactioneaza doar cu frontt-endul (care este pagina de browser)
2) utilizatorul de rand(in context java ee)  semnifica alt dev/noc/admin avand cunostiinte avansata de java ee
3) stacktrace-ul este pe server si nu se transmite pe web (cu anumite exceptii foarte bine definite)

andreim77, on 13 septembrie 2017 - 17:01, said:

In java ee nu exista concept de eroare inutile. In java ee orice eroare sau non-eroare este o  informatie cruciala oferita dev-ului despre comportamentul aplicatiei(inclusiv cele de tip warning)
in java ee,  clientul =  dev de java ee sau programator java ee si nu end-user.

Edited by Qupidqu, 13 September 2017 - 17:20.

dani.user, on 13 septembrie 2017 - 11:17, said:

Depinde în calitate de ce deschizi aplicația. Dacă o deschizi în calitate de utilizator de rând, greșeala e că vezi în primul rând acele mesaje.

Dacă le vezi în calitate de utilizator-programator (utilizator cu cunoștințe de programare dar fără codul sursă, sau cu codul sursă dar plătești pentru suport), atunci trimiți Bug reports.

Dacă în calitate de programator, depinde de contract și/sau licență vs. valoarea identificării și eventual a reparării problemei: abordările se întind de la patchuirea proprie și trimiterea patchului upstream până la plătirea pentru rezolvarea bugului.

Depinde de constelația în care te afli și costurile pe care ești dispus să le suporți (timp, bani, technical debt, know how, etc).

Cel mai probabil fie a facut deployment la o aplicatie pe  un server java, fie a accesat un client consola de tip RMI/JMS  sau un client consola EJB care foloseste JNDI

Mesaj moderator: Nu mai da quote (in intregime) la ultimul post.

Edited by MarianG, 13 September 2017 - 19:07.
quote