[Alg] Exceptions: zin en onzin

[flowerp]

JKVA schreef op zondag 13 mei 2007 @ 17:03:
Ik zou graag zien dat exceptions efficienter worden (in performance), in plaats van dat we eromheen gaan werken.

In Java heb je in SUN VM de (bijna) geheime optie: OmitStackTraceInFastThrow. Deze staat bijna nergens gedocumenteerd. Hij komt alleen ergens in de release notes van een bepaalde Java update voor.

Hiermee worden Fast Throw "Exceptions" een behoorlijke factor sneller, maar heb je geen stacktrace tot je beschikking. Opmerkelijk is ook dat ze het hier een Throw noemen en geen Exception.

Als je Throws gebruikt voor non-exception situaties heb je natuurlijk ook geen stacktrace nodig.

[Confusion]

Verwijderd schreef op zondag 13 mei 2007 @ 13:50:
Dit blijft natuurlijk ten alle tijde zeer discutabel. Wanneer je gaat parsen naar een int verwacht je klaarblijkelijk dat de invoer een int representeert. Dus wat dat betreft is het gewoon een uitzonderlijke situatie als het geen int blijkt te zijn. Weet je niet of het een int betreft dan ben je wellicht op zoek naar een patroon. Daar zijn uiteraard andere middelen voor, zoals bijvoorbeeld regex. Dus nogmaals, zeer discutabel. Een dergelijk stellig, uit zijn context gerukt, citaat gaat dus vrijwel nooit op.

Dat de Integer.parseInt methode een NumberFormatException declareert betekent in mijn ogen dat de methode verwacht dat er weleens een string als invoer zal dienen die niet in een Integer kan worden omgezet. Als de methode dat niet zou verwachten, dan zou het geen exception declareren en een RuntimeException gooien als er toch iets (onverwacht) mis ging.

[Verwijderd]

flowerp schreef op zondag 13 mei 2007 @ 17:19:
[...]


In Java heb je in SUN VM de (bijna) geheime optie: OmitStackTraceInFastThrow. Deze staat bijna nergens gedocumenteerd. Hij komt alleen ergens in de release notes van een bepaalde Java update voor.

Hiermee worden Fast Throw "Exceptions" een behoorlijke factor sneller, maar heb je geen stacktrace tot je beschikking. Opmerkelijk is ook dat ze het hier een Throw noemen en geen Exception.

Als je Throws gebruikt voor non-exception situaties heb je natuurlijk ook geen stacktrace nodig.

Op zich lijkt me dat een goeie oplossing voor de plekken waar je een exception opgooit waar eigenlijk helemaal geen exception is. Zo'n exception zit over 't algemeen vol met gegevens waarmee je kan herleiden waar en waarom 't fout is gegaan (zoals je al noemt, o.a. stacktrace).
Als je dus iets kan opgooien wat niet voor debugging etc. bedoeld is, lijkt 't me een elegante manier om je code te breaken zonder dat 't gezien zou kunnen worden als misbruik van een feature in de taal.

Weet je toevallig ook of er zoiets in C# bestaat?

[Verwijderd]

Verwijderd schreef op zondag 13 mei 2007 @ 21:37:
[...]


Op zich lijkt me dat een goeie oplossing voor de plekken waar je een exception opgooit waar eigenlijk helemaal geen exception is. Zo'n exception zit over 't algemeen vol met gegevens waarmee je kan herleiden waar en waarom 't fout is gegaan (zoals je al noemt, o.a. stacktrace).
Als je dus iets kan opgooien wat niet voor debugging etc. bedoeld is, lijkt 't me een elegante manier om je code te breaken zonder dat 't gezien zou kunnen worden als misbruik van een feature in de taal.

Weet je toevallig ook of er zoiets in C# bestaat?

C#:

#IF DEBUG
#ENDIF

#IF !DEBUG
#ENDIF

Nadeel dat als je component in Release mode gebouwd is, dit natuurlijk ook niet meegenomen wordt. Andere mogelijkheden kan ik me zo ff niet bedenken.

[Verwijderd]

Confusion schreef op zondag 13 mei 2007 @ 18:17:
Dat de Integer.parseInt methode een NumberFormatException declareert betekent in mijn ogen dat de methode verwacht dat er weleens een string als invoer zal dienen die niet in een Integer kan worden omgezet. Als de methode dat niet zou verwachten, dan zou het geen exception declareren en een RuntimeException gooien als er toch iets (onverwacht) mis ging.

Hiermee raak je de discussie: "Wanneer een checked en wanneer een unchecked exceptie te gooien". Een zijstraat waar we ons nu maar even niet in moeten verzanden. Of het nou checked of unchecked is doet natuurlijk voor het verhaal niets ten onder.

[Verwijderd]

Verwijderd schreef op zondag 13 mei 2007 @ 21:43:
[...]

C#:

#IF DEBUG
#ENDIF

#IF !DEBUG
#ENDIF

Nadeel dat als je component in Release mode gebouwd is, dit natuurlijk ook niet meegenomen wordt. Andere mogelijkheden kan ik me zo ff niet bedenken.

Mjah, ik bedoelde dus eigenlijk een soort throwable die geen exception is. Die fast throw zeg maar

[flowerp]

Verwijderd schreef op zondag 13 mei 2007 @ 23:33:
[...]
Mjah, ik bedoelde dus eigenlijk een soort throwable die geen exception is. Die fast throw zeg maar

Ik moet moet nog wel even opmerken dat in Java de VM zelf bepaald of iets een fast throw wordt. Als een throw -echt- een exception is (dwz, maar heel af en toe voorkomt) dan wordt het een normale throw. Detecteert de VM echter dat een throw vaak voorkomt, dan optimaliseert ie hem zelf naar een fast throw.

Als je in je Java applicatie een handler hebt die exceptions print, dan merk je dat je op een gegeven moment opeens stack traces mist voor 'veelvoorkomende exceptions' (tegenspraak eigenlijk ).

[roy-t]

flowerp schreef op donderdag 10 mei 2007 @ 22:18:
[...]


Lees nog eens terug wat ik schreef Voor geneste loops een goto/'break to label', maar in ieder geval in Java kan dat niet als je nestings bestaan uit method calls. Je gebruikt dan een exception (generieker: stack unwind) om uit de nested methods te 'breaken'.

Performance is geen issue als je nestings bestaan uit 1000'en itteraties en je er slechts 1 maal uit breaked.

Ahh java excuses