ugrás a tartalomhoz

Kivétel kezelés kérdés!

Karvaly84 · 2011. Szep. 23. (P), 09.35
Helló guruk!

Olyan dolgot szeretnék megoldani, hogy van egy függvény ami meghív egy másik függvényt, ebben a másik függvényben szeretnék hibát dobni. Két kérdésem lenne evvel kapcsolatban.

1. Az értelmező csak akkor generál hibát ha a throw után az Error egy leszármazottja van? Vagy elég ha az objektum megvalósítja ugyan azt az interfészt, de semmi köze az Error-hoz? Mert gondolkodok egy olyan Osztályon ami a natív Error-t terjeszti ki vagy egy uj osztály bevezetésén az Object-ből.

2. A call stack egy felsőbb szintjét hogy tudnám elérni? Mert a hiba helyét (sorszámát) szeretném ha az Error objektumom tartalmazná.
‹ HTML mail káosz Js elrejtés - megjelenítés ›
 ■
1

A másodikhoz a

Hidvégi Gábor · 2011. Szep. 23. (P), 10.00
A másodikhoz a debug_backtrace() függvényre lehet szükséged.
2

ez a függvény a debugger

Karvaly84 · 2011. Szep. 23. (P), 10.05
ez a függvény a debugger része vagy a js engine biztosítja és minden platformon van? minjá rá keresek közbe. köszönöm!
4

Bocs, most látom csak, hogy

Hidvégi Gábor · 2011. Szep. 23. (P), 10.09
Bocs, most látom csak, hogy milyen témában vetetted fel, ez php függvény.
3

közbe nézem ez php amit írtál

Karvaly84 · 2011. Szep. 23. (P), 10.08
közbe nézem ez php amit írtál :) én most js-ben probálom ezt kivitelezni :)
5

Ha jól emlékszem nem nagyon

inf · 2011. Szep. 23. (P), 10.26
No nekifutok újra :-)

Dobni bármivel lehet kivételt, stringgel is akár. A toString amit használ az értelmező, hogy kiírja a szövegét a dolognak.

Az interface az gyakorlatilag nem létezik az Error osztálynál sem, van name és message property rajta, meg a konstruktora elfogad message-t, vagy semmit. Ez nem interface. A line és a fileName nincsenek benne, talán debug backtrace-ből ezek visszanyerhetőek, de ha jól tudom ez msie-ben nem megoldás.
6

Akkor nem is kel származtatni

Karvaly84 · 2011. Szep. 23. (P), 10.51
Akkor nem is kel származtatni az Error-t ezek szerint, explorer egyébként, "kezeletlen kivétel" áll le ha nem az Error példányát dobom fel hiába van message propertyje de most kipróbáltam a kód végrehajtása megáll a sima stringre is de akkor sem írja ki magát a szöveget sajna. a Call stack-re meg nézeggetem pár megoldást de nem igazán böngésző független a dolog "arguments.callee.caller" ez úgy tudom nem mindenhol van, meg pont volt már erről szó hogy ez elavult, más megoldást meg nem ismerek, hogyan érjem el a hívó függvényt. Marad a try/catch
7

Egyébként azért kérdeztem ezt

Karvaly84 · 2011. Szep. 23. (P), 10.55
Egyébként azért kérdeztem ezt a dolgot, mert amiről valamelyik nap beszéltünk, function overload abba szeretnék ilyen dolgokat be építeni, hogy ha rossz argumentumokkal hívnak egy függvényt dobjon rá kivételt, egyébként a típusokat most a natív typeof-ra bítom de majd fejlesztem a null-ra meg a array-ra, a instanceof meg felejtös mert explorerben a window [object Object] és nem [object Window] a constructora meg undefied...
8

Hát én próbáltam

inf · 2011. Szep. 23. (P), 11.52
Hát én próbáltam cross-browser megcsinálni annak idején, de nekem nem jött össze. Helyette inkább azt választottam, hogy minden osztály és metódus tudja a saját nevét, és amikor mondjuk típusokkal van gond, akkor a metódus nevét, a paraméter nevét az elfogadott és a hibás típus nevét is hozzácsatolja a message-hez. Így már kis szerencsével meg lehet találni, hogy mi az ami nem stimmel.

Azért használok ilyen szintaxist, mert így minden osztály bekerül egy központi fába, és meg lehet határozni egy path-et hozzá. Ugyanez a helyzet a metódusokkal is.

$(
{
	"package A":
	{
		"class B":
		{
			typens:
			{
				a: String,
				b: "String"
			},
			"overload method":
			[
				function (a, b)
				{
					
				},
				function (a)
				{
					
				}
			]
		}
	}
})
Egyelőre én nem találtam ennél jobb megoldást, de hajrá, hátha neked sikerül! :-)
9

Hát asszem én sem keresek

Karvaly84 · 2011. Szep. 23. (P), 15.37
Hát asszem én sem keresek tovább megoldást, nem szeretnék túl nagy kód bázist , felesleges... Gondolkodtam és arra jutottam javascript-ben szerintem simán elég ha csak megkülönböztetjük a string-et meg az object-et és hasonló, és nem instanceof-al operálunk. Az, hogy ez cross-browser legyen több száz plusz sort jelent és nem biztos hogy szükség van rá. De terméseztessen szerintem jó dolog hogy a funkcioknak tudunk szignatúrát adni még ha csak ilyen alap szinten is ami a typeof-ra alapul. Úgy hogy szerintem nem fogok töprengeni hogy oldjam meg a MSIE hibáit.

A vége az hogy marad ez a felület:

function fn() {
	fn.form.call(this, arguments);
}

fn.overload('string', 'string', function(a, b) {
	console.log(a + ' ' + b);
});
ahol a paraméterek típusa string típusként vannak megadva amit a typeof add vissza, ha ez nem egyezik akkor dobunk hibát. tovább nem kínlódok evvel a dologgal.