Quali sono le comuni / migliori pratiche per i framework che gestiscono eccezioni standard di terze parti?

3

Tra le altre cose nella mia vita, sto scrivendo una struttura in PHP per gestire una serie di problemi comuni a cui mi imbatto in ogni progetto che affronto. Il framework è attualmente molto incentrato sui dati, con il componente più grande (denominato Data) che fa parte ORM e parte DDD nel suo approccio.

L'ORM-ness di questo componente astrae pesantemente le query al punto che lo sviluppatore non ha bisogno di conoscere alcun SQL o nemmeno conoscere la terminologia SQL. Il motivo principale alla base di tutto ciò deriva dalla mia esperienza come DBA / BIDev, in cui mi sono lamentato di molte delle query costruite male dagli appassionati di SQL che facevano cose complicate piuttosto che l'approccio più semplice e diretto. Ad esempio, il codice seguente verrebbe r SELECT ... FOR UPDATE dalla tabella user dove username è 'jennifer':

$userFilter = $userRepository->createBlank();
$userFilter->username()->identifyValue('jennifer');
$userFilter->lockForUpdate();
$user = $userRepository->retrieve($userFilter);

Metto alla prova il mio framework contro diverse applicazioni con cui sono coinvolto, il che significa che posso prendere in giro scenari di fuoco vero e proprio. Nei test recenti, mi sono imbattuto nel seguente errore:

SQLSTATE[0A000]: Feature not supported: 7 ERROR: FOR UPDATE is not allowed with window functions Failed query is: SELECT * FROM "myView" WHERE "ID"=:fi_ID__ix0 FOR UPDATE;

Si scopre che la vista myView contiene una colonna generata da una funzione OLAP / finestra (cioè ROW_NUMBER() OVER(PARTITION BY...) , il che significa che la vista non può essere selezionata per l'aggiornamento.L'errore è stato generato da PostgreSQL, è interamente legittimo, ed è naturalmente in risposta a questa operazione non valida.

Quello che mi chiedo è, quali sono i modi comuni / accettati che i framework gestiscono problemi di terze parti come questo? Pubblica il messaggio di errore letteralmente e lascia che lo sviluppatore lo calcoli o prova ad aggiungere valore al messaggio suggerendo problemi o vie di indagine comuni?

    
posta e_i_pi 27.01.2018 - 10:40
fonte

2 risposte

2

Il tuo framework è un livello di astrazione. Ma tutte le astrazioni perdono. Non puoi coprire tutti i casi, per tutti i database conosciuti, quindi hai finalmente bisogno di affidarti a uno sviluppatore nonostante questa situazione tu stia citando:

... this comes from my experience as a DBA/BIDev, where I groaned over many of the poorly constructed queries by SQL amateurs that convoluted things...

Non puoi proteggerli quando qualcosa va storto. Quindi, invece, dai loro tutte le informazioni necessarie per risolvere la situazione (ad esempio l'eccezione effettiva).

Tuttavia, l'applicazione client non deve avere a che fare con eccezioni di database diverse. Il tuo framework dovrebbe avere le sue eccezioni. Le applicazioni gestiranno tutto ciò che proviene dal livello dati utilizzando solo le eccezioni del framework, senza conoscere l'implementazione sottostante della particolare tecnologia di database.

Le eccezioni del framework avvolgono quelle originali. Le applicazioni reagiscono alle tue eccezioni mantenendo tutto omogeneo tra le modifiche del database, mentre allo stesso tempo hai tutto il necessario per eseguire il debug all'interno dell'eccezione originale (puoi sostituire le eccezioni che potrebbero venire dal database con le tue ma la maggior parte delle volte è meglio avvolgi solo quelli del database sottostante per evitare di perdere qualsiasi informazione quando qualcosa non funziona come non ti aspettavi o anticipavi).

    
risposta data 27.01.2018 - 13:35
fonte
1

Throw the error message verbatim and let the developer figure it out, or try to value-add to the message by suggesting common problems or avenues of investigation?

Entrambe le opzioni sembrano corrette. Vorrei basare la mia decisione sulle informazioni fornite dal provider della biblioteca.

Alcune librerie (in generale quelle costruite per scopi non commerciali) sono molto "spartane" nei dettagli e nella documentazione. Tutti abbiamo visto (di tanto in tanto) messaggi di errore come:

Error. Incorrect data

Oh uomo! Cosa diavolo dovrebbe significare? Ho inviato dati errati? Formati sbagliati? Intervalli errati? Cosa è andato storto?!?!

Se riesci a nascondere questo abominio, se puoi dare più contesto e feedback, gli sviluppatori lo apprezzeranno. Un sacco. E così tutti gli altri coinvolti nel progetto.

D'altra parte, ci sono librerie (e prodotti) molto ben documentate che gli sviluppatori si prendono cura di questi dettagli. Il tuo esempio può essere buono.

PostgreSQL sta già fornendo informazioni sufficienti per gli sviluppatori per la ricerca. Ad esempio, iniziando cercando ciò che SQLSTATE[0A000] significa. È un codice di errore e probabilmente è documentato da qualche parte . Quindi, chiunque abbia creato il driver per PostgreSQL in PHP, non ha osato aggiungere singolo coma ai messaggi di errore. Non c'è bisogno! E così chiunque costruisca un framework su questo driver.

È probabile che entrambi, errore e soluzione, saranno documentati da coloro che lo hanno già sofferto.

What I'm wondering is, what are the common/accepted ways that frameworks handle third-party problems like this?

Ogni framework si occupa della sua esperienza di sviluppo . Ecco di che cosa si tratta. Diversi quadri potrebbero affrontare lo stesso problema da diverse direzioni.

Quindi, non mi interesserebbe troppo a quello che fanno gli altri framework. Mi concentrerei sull'esperienza di sviluppo che voglio dare. Come vorrei che gli sviluppatori si sentissero con il mio framework? Se trovassi altri framework che esperienza di sviluppo e il mio sono uguali, prenderei nota, ma non prenderei i loro approccio come la strada da percorrere. Solo un altro approccio che potrei adottare.

Potresti essere interessato

Domande correlate

risposta data 27.01.2018 - 13:52
fonte

Leggi altre domande sui tag