watek monitorujacy

hej,
chcialabym napisac watek monitorujacy zachowania w programie. Wlasciwie to mialby dzialac tak, ze jak w jakims miejscu wystapi Exception to ma to isc do tej klasy i tam jakas obsluga tego i odpowiednia akcja. Nie wiem jednak jak zaprojektowac taka klase. Zgrubny szkielet to cos w tym stylu:

 
public class Test extends Thread{
		
	public void run(){
		
		while(true){
			
			
		}
	}
	
	public void catchException(Exception e){
		//TODO: logic here
	}
	
}

no i nie wiem jak dalej. watek ma chodzic ciagle - wiec jest petla while(true). Ma tez metode ktora ma byc wywolywana w przypadku wystapienia Exception gdzies w jakims miejscu programu - catchException. no i co dalej? czy w runie wystarczy tylko petla while(true) ? czy tam powinna byc jakas logika? a moze metoda catchException powinna znajdowac sie w innej klasie?
co sadzicie?

bede wdzieczna za wszystkie sugestie.

     pzdr,
              misty

Moze Thread.setDefaultUncaughtExceptionHandler?
Osobny watek sam z siebie nie umie lapac wyjatkow innych watkow. Musialabys zrobic ten watek i jakas kolejke, w ktorym ten osobny watek zbiera wyjatki z kolejki, a wszystkie inne watki na nia dokladaja. Powszechnie znany model Producent - Konsumer (gdzie producerow masz wielu, tyle ile watkow w aplikacji, nie liczac tego jednego Konsumera). Taka architektura ma ten problem ze do kazdego watku musisz dostarczyc kolejke, wzglednie uczynic ja globalnie dostepna (nieladny static). Jak koniecznie tego chcesz to uzyj jakiejs kolekcji ktora jest thread-safe, jak np ArrayBlockingQueue czy podobne.

jeny w ogole nie pomyslalam ze to powinno byc w jakiejs kolejce :/
sklonilabym sie do uzycia jakiegos gotowego rozwiazania skoro takie istnieje i byloby dla mnie wystarczajace. czyli moja klasa zamienia sie w cos takiego:

public class Test implements UncaughtExceptionHandler{

	@Override
	public void uncaughtException(Thread t, Throwable e) {
		// TODO: logic here
		
	}
	
}
 

czy tak? i teraz pare moich pytan bo troche nie kumam jak tego uzyc. Ja chce miec taki jeden watek monitorujacy. Gdybym z tej klasy Test zrobila singleton to wtedy w kazdym miejscu programu w ktorym chcialbym uzyc tego ExceptionHandlera, mialabym jedna instancje a nie N. ale czy tak moge? i pozniej:

<code = java>
Test test = Test.getInstance();
Thread.setDefaultUncaughtExceptionHandler(test);

//i pozniej

test.uncaughtException(this, exception);

czy takie rozwiazanie spowoduje mi ze bedzie odpowiednia obsluga? przez odpowiednia rozumiem, ze np wystapi exc w watku A i B, to uncaughtException obsluzy ladnie, po kolei A i zaraz B? czy ja to dobrze kumam?

  pzdr i dzieki za odpowiedz,
        misty

kurde, a czy to nie jest tak, ze samo mi powinno przechodzic do tej metody uncaughtException? i czy nie przejdzie dopiero gdy przyjdzie jakis uncaughtException (jak nazwa wskazuje)? a w zwyklym try-catch to nie zadziala?

Moim zdaniem koncepcja jest zła. Jeżeli wyskoczy gdzieś wyjątek, to jeżeli obiekt w którym on wystąpi potrafi go obsłużyć, to go złapie. Jeżeli tego nie potrafi, to wyjątek przekazywany jest "wyżej". Skoro więc wyjątek nie zostanie przechwycony, to po co jakiś kod miałby go wracać z powrotem tam, gdzie nie mógł zostać obsłużony? Jaki miałby być ostateczny cel takiego "monitorowania"? Czemu miałoby to służyć?
Najpierw musisz na te pytania sobie odpowiedzieć i dobrze uzasadnić potrzebę istnienia takiego monitora.

Koncepcja nie jest zla. ale moze za malo szczegolowo opisalam o co mi chodzi. Wyobraz to sobie tak: masz N-watkow w aplikacji, robia rozne rzeczy, czasem sypna jakims exceptionem. Ja chce miec takiego zarzadce-czyli kolejny watek do monitorowania tych watkow i obslugi bledow. A przez to rozumiem cos takiego ze jak z jakims watkiem cos sie stanie (rzucony exception) to pojdzie to do zarzadcy. Zarzadca zaloguje tresc wyjatku i wykona odpowiednia akcje (np zakonczy dzialanie watku). I do czegos takiego szukam rozwiazania projektowego.

OK, ale taki manager musiałby wiedzieć do czego służy kod w poszczególnych wątkach. A przecież jedne wątki będą usługowe dla innych (np. akcje zainicjowane przez GUI), a inne mogą być samodzielne (np. sterować jakimś procesem produkcyjnym). W każdym wypadku taki manager musiałby rozumieć strukturę logiczną aplikacji i traktować każdy wątek indywidualnie. Jednak najlepsza informacja o tym jak wybrnąć z sytuacji awaryjnej w wątku ma kod, który taki wątek powołał do istnienia, a nie jakiś osobny manager. Dlatego istniejący mechanizm (podany wyżej) jest zwykle zupełnie wystarczający.

Zgadzam sie z Olo, z jednym wyjatkiem - czasami sa sytuacje ze kazdy wyjatek, bez wyjatku ;d musi byc obsluzony w taki sam sposob - moze to byc jedyny kod ktory zajmuje sie tym wyjatkiem, a moze to byc tylko mala czesc handlera. Widze np logowanie czy wysylanie maili czy cokowiek jako przyklad. Mozna wtedy zrobic osobna klase managera, ktora ten wspolny kod wywoluje, i albo managera wstrzykiwac / uzywac statyczna metode, albo wrzucac na kolejke i manager sobie z niej sciaga i obsluguje. Ten drugi przyklad (z kolejka) ma sens tylko wtedy jesli spodziewamy sie ze wyjatkow moze byc tak duzo ze ich obsluga moze zawalic system - wtedy kolejka troche spowolni ta obsluge. Jest to przyklad z mojego aktualnego projektu, gdzie szef / team lead sie uparl na takie rozwiazane, ktore uwazam ze glupie i zbedne. Pomijam juz fakt ze u nas wysylanie na kolejke wyjatkow / obsluga jest zaimplementowana za pomoca JMS i MDB <lol>