Autore Topic: Catch o altro?  (Letto 785 volte)

Offline Picavbg

  • Senatore Gambero
  • ******
  • Post: 1.620
    • Mostra profilo
Catch o altro?
« il: 10 Marzo 2011, 23:15:28 »
Sto revisionando il mio programma, allo scopo di renderlo più snello; per farmi capire meglio: sto eliminando tutte le variabili globali che avevo usato all'inizio del mio cammino con Gambas.
Ho voluto mettere un punto adesso, anche se ancora c'é molto da fare, ma così com'é, già funziona, ... ho detto "funziona", ...non ho detto "funziona perfettamente" :D
Perciò penso che sia arrivato il momento di farlo conoscere alla nostra comunità; tuttavia devo limarlo ancora un pò ed oggi, nella prova di creazione automatica del DB, mi sono beccato un errore nell'istruzione if exist. Ciò é avvenuto dopo avere tolto il TRY nella open della connessione.
Ho visto che l'unico modo che avrei per non fare fermare irrimediabilmente il programma, é quello di inserire un'istruzione CATCH, mai digerita.
Ho perciò necessità di sapere due cose:
1) esiste un'alternativa alla CATCH (che non sia TRY ovviamente)?
2) se inserisco una CATCH dentro una Form essa agisce solo per le condizioni di errore relative a quella Form o anche per quelle di altre Form?
 ???
Saluti.
:ciao:

Offline fsurfing

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.482
    • Mostra profilo
Re: Catch o altro?
« Risposta #1 il: 11 Marzo 2011, 20:39:04 »
se metti una cath in una funzione questa è valida solo all' interno di quella funzione o al limite anche all' interno di altre funzioni richiamate dalla funzione stessa.

a me il cath piace anche perche lo utilizzo per scrivere all' interno di un file log l' errore , inoltre se eseguo delle scritture con db   inizializzate con un begin  , in caso di errore non fa il commit e mi fa un roolback cancellandomi anche eventuali altre scritture precedenti che siano sempre all' interno del begin , ma a me piaciono anche le variabili globali , ammesso che per variabili globali intendiamo la stessa cosa :) tu per variaili globali cosa intendi?

inoltre non capisco cosa ti serva il try nella open della connessione ,dovresti sapere già a priori che in una parte di funzione la connessione e aperta ed in altre no
« Ultima modifica: 11 Marzo 2011, 20:43:43 da fsurfing »

Offline Picavbg

  • Senatore Gambero
  • ******
  • Post: 1.620
    • Mostra profilo
Re: Catch o altro?
« Risposta #2 il: 11 Marzo 2011, 23:07:23 »
se metti una cath in una funzione questa è valida solo all' interno di quella funzione o al limite anche all' interno di altre funzioni richiamate dalla funzione stessa.

a me il cath piace anche perche lo utilizzo per scrivere all' interno di un file log l' errore , inoltre se eseguo delle scritture con db   inizializzate con un begin  , in caso di errore non fa il commit e mi fa un roolback cancellandomi anche eventuali altre scritture precedenti che siano sempre all' interno del begin , ma a me piaciono anche le variabili globali , ammesso che per variabili globali intendiamo la stessa cosa :) tu per variaili globali cosa intendi?

inoltre non capisco cosa ti serva il try nella open della connessione ,dovresti sapere già a priori che in una parte di funzione la connessione e aperta ed in altre no
Sarà perché quando ho provato, tempo fa, la CATCH dentro un'struzione d'accesso al DB  per registrare un nuovo record o altro, adesso non ricordo, ho avuto la sgradita sorperesa di vederla attivare anche in un passo di programma, interno alla stessa form, senza averne richiesto l'uso. Allora l'ho interpretata come malfunzionante e da quel momento mi sono ben guardato dall'usarla. Io non uso il file di log per risalire all'errore, ma sempre e soltanto MessageBox.

Ai primi approcci con Gambas ho usato l'istruzione di  controllo try nelle open di una connessione perché utilizzavo male le query sql. Ora sono un pò più sicuro, ma utilizzo ancora la try nelle istruzioni di scrittura record nel DB, perché altrimenti, in caso di errore il programma s'interrompe con l'emissione di messaggi forniti da Gambas, quindi, al di fuori del controllo da parte del programma stesso. Perciò trovo più comodo e pertinente mantrenere tutto sotto il controllo del mio codice. Es.:
Codice: gambas [Seleziona]
 ApriDB = NEW OpenDB
  i_id += 1
  TRY OpenDB.DB_Connection.EXEC("INSERT INTO piancont VALUES(" & i_id & ", '" & Int(Val($_RgTbDump[0])) & "', '" & $_RgTbDump[1] & "', '" & $_RgTbDump[2] & "', '" & Int(Val($_RgTbDump[3])) & "')")
  IF ( ERROR ) THEN
      Message.ERROR("Attenzione!  ERRORE --> '" & ERROR.Text & "'" & Chr(10) & "alla riga " & Error.Where & Chr(10) & Chr(10) & "durante la registrazione della '" & OpenDB.$_DbNome & "!piancont'" & Chr(10) & Chr(10) & Space$(30) & " IL PROGRAMMA VERRÀ CHIUSO")
      QUIT
  ENDIF

Come puoi notare, la presenza di  ERROR.Text e di  Error.Where mi permettono di catturare l'errore in forma chiara con l'indicazione della riga di programma dove l'errora possa manifestarsi.

Cosa intendo per variabili globali? Non capisco la domanda perché credo di non avere dubbi in proprosito, ma non ho niente in contrario a rispondere alla tua domanda: considerato che le variabili locali sono dichiarate con l'istruzione DIM all'interno di una procedura, tutte le altre, siano esse PRIVATE o PUBLIC, sono variabili globali. Occorre però conoscere l'estensione della loro efficacia, per cui una variabile Public|Privata, dichiarata all'inizio di una classe o modulo, è riconosciuta ed accessibile intanto all'interno di tutta la classe o di tutto il modulo; però la variabile dichiarata come PUBLIC può essere acceduta anche da qualsiasi altra classe o qualsiasi altro modulo del progetto e resta attiva per tutta la durata del programma stesso.
Spero di avere risposto bene alla prova d'esame.  ;) Se ho sbagliato il concetto, ti prego di correggermi. Comunque tornando al mio intendimento di eliminare le variabili globali dal mio programma, intendo dire che ho eliminato tutte le variabili definite a suo tempo PUBLIC all'interno di uno dei moduli che conteneva il programma e che richiamavo  di volta in volta con una sintassi del tipo: Modulo1.Variabile1. Per la loro peculiarità mi sembra sprecato tenerle attive per tutta la durata del prgramma, quando  le utilizzo soltanto saltuariamente.

Sono entrato nell'ottica del risparmio di memoria, il più possibile, ed ho deciso di farne a meno da ora in avanti.
 :ciao: :ciao:
:ciao:

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Catch o altro?
« Risposta #3 il: 13 Marzo 2011, 15:14:48 »
NOTA: le istruzioni TRY...CATCH sono, come per tutti i linguaggi, usate per intercettare errori non previsti. Durante la codifica di un programma, si deve cercare di pensare a tutte le possibili causa di un errore ma, in certi casi questo non è possibile (non è possibile conoscere tutto a priori). Dato questo, l'implementazione di un sistema generico che, comunque, intercetti errori anomali non previsti, credo sia una mano santa. Alternative non ce ne sono...
E' da tener presente che oggi, spesso e volentieri, si ha a che fare con applicazione che interagiscono con altre applicazioni (esterne), delle quali non si possono prevedere tutte le eventuali anomalie. Nel caso di un gestionale che si collega ad un database (che è sempre esterno), deve poter prevedere che questo si può comportare in malo modo, anche a seguito di una richiesta anomala da parte del nostro applicativo. Noi possiamo prevedere il comportamento in determinati casi, ma non i tutti, per cui è buona norma prevedere un sistema che controlli, o perlomeno intercetti, anomalie non previste, come in questo caso TRY...CATCH.

Offline Picavbg

  • Senatore Gambero
  • ******
  • Post: 1.620
    • Mostra profilo
Re: Catch o altro?
« Risposta #4 il: 14 Marzo 2011, 00:28:14 »
NOTA: le istruzioni TRY...CATCH sono, come per tutti i linguaggi, usate per intercettare errori non previsti. Durante la codifica di un programma, si deve cercare di pensare a tutte le possibili causa di un errore ma, in certi casi questo non è possibile (non è possibile conoscere tutto a priori). Dato questo, l'implementazione di un sistema generico che, comunque, intercetti errori anomali non previsti, credo sia una mano santa. Alternative non ce ne sono...
E' da tener presente che oggi, spesso e volentieri, si ha a che fare con applicazione che interagiscono con altre applicazioni (esterne), delle quali non si possono prevedere tutte le eventuali anomalie. Nel caso di un gestionale che si collega ad un database (che è sempre esterno), deve poter prevedere che questo si può comportare in malo modo, anche a seguito di una richiesta anomala da parte del nostro applicativo. Noi possiamo prevedere il comportamento in determinati casi, ma non i tutti, per cui è buona norma prevedere un sistema che controlli, o perlomeno intercetti, anomalie non previste, come in questo caso TRY...CATCH.
:coder:
 :ciao:
:ciao: