Andere talen die Carp (van Perl) kennen/kunnen?

[Juup]

Ik zat laatst wat te stoeien met Go en het viel al snel op hoe ellendig de errors zijn die er uit komen. Net als in Java en vele andere talen eigenlijk: lange stacktraces.

Weet iemand of er talen zijn die net als Perl's Carp een error kunnen gooien vanuit het perspectief van de aanroeper van de functie?

Perl:

#!/usr/bin/perl
use Carp qw(carp);

sub g {
    my $x = shift;
    carp "Parameter needs to be a number" if $x =~ /\D/;
    return $x;
}
g("x");

Parameter needs to be a number at carp.pl line 9

[Ed Vertijsment]

Juup schreef op donderdag 7 november 2019 @ 21:36:
Ik zat laatst wat te stoeien met Go en het viel al snel op hoe ellendig de errors zijn die er uit komen. Net als in Java en vele andere talen eigenlijk: lange stacktraces.

Weet iemand of er talen zijn die net als Perl's Carp een error kunnen gooien vanuit het perspectief van de aanroeper van de functie?

Perl:

#!/usr/bin/perl
use Carp qw(carp);

sub g {
    my $x = shift;
    carp "Parameter needs to be a number" if $x =~ /\D/;
    return $x;
}
g("x");

Parameter needs to be a number at carp.pl line 9

Ik ben niet echt bekend met Go of Java, maar stack traces zijn juist goed. Toen ik nog met Perl werkte gebruikten we overigens dit ook niet. Soms crasht er iets dieper dan je eigen software en dat is het pad terug wel belangrijk. Bijna elke taal kan overigens volgens mij wel een custom error gooien.

[Sleepkever]

Je zou inderdaad vrij simpel in bijvoorbeeld Java een eigen errorhandler kunnen schrijven die een exception pakt en alleen de laatste regel van de stacktrace pakt, daar de foutmelding, regelnummer en bestandsnummer terug geeft en die print naar je log.

Alleen even een voorbeeld van de situatie die Ed hierboven beschrijft. Stel je krijgt ergens een NullpointerException (want het is Java, zo is het leven nou eenmaal), in een gedeeld bestand op regel 100. De functie die regel 100 bevat word gebruikt op 100 verschillende plekken en het object wat null is word meegegeven aan die functie. Hoe ga je er nu achter komen op welk van deze plekken er een `null` mee gegeven word aan die functie met de informatie die je hebt? Een stacktrace is hierbij onmisbaar.

Je hebt wel een punt hoor, de meeste error meldingen kunnen een stuk gebruiksvriendelijker. Runtime vrees ik dat stacktraces een veel te waardevolle toevoeging blijven maar compiler errors zouden een stuk vriendelijker en duidelijker kunnen.

Een redelijk beroemd voorbeeld is misschien wel

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM

Weet jij wat hier mee het probleem is? Ik in mijn noob tijdperk niet namelijk... Een error melding zoals

Unexpected '::' on line 5 in file test.php

5|  return $cnf::getConfig($key);
               ^^
It appears getConfig is not a static function, use '->' to access object level function or make the function static.

Had mij in die tijd veel op weg geholpen. Bovenstaande is overigens een fictief voorbeeld van hoe ELM compiler errors terug geeft, maar dan voor PHP. Maakt de taal als beginner een stuk prettiger om mee te werken. Gelinkte blog levert een stukje gedachtegang waarom dat gedaan is wat wellicht interessant is om te lezen.

Nadeel hiervan is wel vaak dat je later, als je weet waar de error voor staat, een flink stuk eigenlijk overbodige tekst voor je gezicht krijgt. Als je even snel wat wilt weten wat er nou precies stuk is op die regel en je krijgt een lap tekst voor je gezicht van 20 regels is dat wat minder snel te begrijpen dan die ene regel technische beschrijving die je al 1000 keer gezien hebt. Elk voordeel heeft ook z'n nadeel zullen we dan maar zeggen.

[ACM]

Juup schreef op donderdag 7 november 2019 @ 21:36:
Ik zat laatst wat te stoeien met Go en het viel al snel op hoe ellendig de errors zijn die er uit komen. Net als in Java en vele andere talen eigenlijk: lange stacktraces.

Die stacktraces krijg je alleen als je zelf niks doet met de exception.

Weet iemand of er talen zijn die net als Perl's Carp een error kunnen gooien vanuit het perspectief van de aanroeper van de functie?

Dit concrete voorbeeld lijk je te gebruiken voor inputvalidatie. Bij static typed talen heb je dat 'intern' sowieso minder nodig (hooguit nog null-checks) en voor inputvalidatie is simpelweg exceptions opgooien niet per se heel mooi.
Daar is een exception lang niet altijd de beste manier om de gebruiker over te informeren, zeker niet als er meerdere fouten kunnen zijn. Of als je een exception opgooit, kan je die zodanig specifiek maken dat er in de lagen erboven wat nuttigs mee gedaan kan worden.

Maar als je per se carp-gedrag wilt; in Java (en andere talen) kan je ook toegang tot de stacktrace krijgen zonder een exception te moeten gooien. Dus je kan dan je 'carp'-utility zo maken dat ie de foutmelding geeft en voor de aanroep 2 plekken terug (zichzelf en de directe aanroeper overslaan) in de stacktrace kijkt voor 'de aanroepende regel'.
Dat kan in ieder geval via Thread.currentThread().getStackTrace() of via new Throwable().getStackTrace().

En als je dan eindigt met een System.exit(1) heb je ook nog de bijbehorende exit die je in perl kreeg

[Juup]

Ah ja dus het is iig in Java (en vast in meer talen) wel te maken.
Het zou zelfs idd in een globale ErrorHandler kunnen...
Daar ga ik eens mee spelen.

[Ben(V)]

Ik zou als ik you was eens naar Python kijken.
Erg gebruikers vriendelijk, simpel te leren maar erg krachtig.

Uiteraard moet je natuurlijk wel exceptions netjes afvangen maar dan krijg je ook een prima error melding.
En je kunt heel simple self exceptions erbij definieren met je eigen meldingen.

[ Voor 15% gewijzigd door Ben(V) op 13-11-2019 16:13 ]

[Juup]

Ben redelijk bekend met Python en vond het geweldig (door de indentation) maar veel dingen zijn in Python zo brak uitgewerkt dan het onwerkbaar wordt.
Bijvoorbeeld multiprocessing.
Python heeft een echte architect nodig en dat is die van Rossum dus blijkbaar niet.