Norsk for 'raise an exception'?
Hallvard B Furuseth
må oversette tilbake til engelsk for å skjønne?
Og 'catch an exception', for den saks skyld.
Vi har norsk for interrupt, signal og error, men norske exceptions
kjenner jeg ikke til.
--
Hallvard
Bjørn Brox
Ordet signal kan vel brukes?
Sende ett signal.
Flagge ett unntak?
--
Bjørn Brox
Jon Haugsand
Følgende er brukt, og gir en ganske direkte oversettelse:
Throw an exception - Kaste et unntak
Catch an exception - Fange et unntak
Exception handling - Unntakshåndtering
--
Jon Haugsand
Dept. of Informatics, Univ. of Oslo, Norway, mailto:jon...@ifi.uio.no
http://www.ifi.uio.no/~jonhaug/, Phone: +47 22 85 24 92
Haakon Nilsen
> Catch an exception - Fange et unntak
Eller å gripe et unntak. Synes kasting og griping illustrerer ganske fint
hva som skjer. :)
--
Min virkelige mailadresse er rot13(unn...@avyfra.pbz).
Trond Norbye
Ehh.. og hva skal man med norske uttrykk på slikt?? det blir bare idioti
dersom man på død og liv skal "finne på" norske (uforståelige) begrep
på veletablerte engelske uttrykk... tenk bare på hvor idiotisk bitgruppe
høres ut...
Trond
Haakon Nilsen
> Ehh.. og hva skal man med norske uttrykk på slikt?? det blir bare idioti
Synes det er vel så idiotisk å snakke om å traue og kætsje eksæpsjæns i
dagligtale. Språket vårt er norsk tross alt, og om jeg snakker om å kaste
et unntak, forstår alle noenlunde erfarne programmerere meg. På samme måte
som det er vanlig å si Java-bønner istedet Java-beans, eller for den saks
skyld epost istedetfor email.
> dersom man på død og liv skal "finne på" norske (uforståelige) begrep
Hvis du synes at kasting av unntak er uforståelig, har du kanskje ikke
jobbet med slike egenskaper i programmeringsspråk før.
> på veletablerte engelske uttrykk... tenk bare på hvor idiotisk bitgruppe
> høres ut...
Det er ikke et ord jeg kan huske å ha brukt, men ordet virker både
forståelig og utvetydig i min mening.
XFUT til no.fag.spraak.fagord, der dette temaet hører bedre hjemmme.
Torkel Holm
> Jon Haugsand wrote:
>
>> Catch an exception - Fange et unntak
>
> Eller å gripe et unntak. Synes kasting og griping illustrerer ganske fint
> hva som skjer. :)
Synes kasting og misting passer bra :) (ok, den var intern)
Eller brukes vel throw og raise nokså synonymt når det gjelder
python-litteraturen som jeg formoder OP bruker (eller modula-3?).
Dermed funker det greit med kasting av unntak. Det skal være sagt
at dette på ingen måte er et universelt uttrykk i en verden av
unntaksystemer.
--
Torkel Holm
Jostein Berrefjord
> Ordet signal kan vel brukes?
> Sende ett signal.
I den aktuelle konteksten - dvs. programmering - kan "signal" allrede
være definert med en annen syntaks; det gjelder f.eks. i CHILL.
Vi bør ikke ha oversettelser av generelle begreper som er avhengig
av hvilket programmeringsspråk som brukes. Og selv om ikke språket
definerer begrepet, kan det likevel være et viktig konsept i
anvendermiljøet. F.eks. i telebransjen er "signalering" et grunnleggende
begrep som ikke har noe med unntak å gjøre.
> Flagge ett unntak?
Liker uttrykket, men det bringer inn i diskusjonen *hva* vi egentlig
prøver å finne en betegnelse på. (Det er kanskje ikke så mye mer
veldefinert på engelsk.) Jeg oppfatter det å "flagge" et unntak
som noe du gjør *etter* at den reelle unntakssituasjonen har
oppstått - en påpeking, merking, av det som skjedde. Ut fra det
vil ikke en divisjon med null "flagge" et unntak - flagging (som
unntak) er noe avbruddsrutina gjør når den aktiveres.
Det er nok dette som er den mest vanlige bruken i programmerings-
sammenheng (fordi programmerere stort sett handterer unntak etter
at de har oppstått!). Men du hører/leser også stadig vekk
formuleringer som "Dividing any nonzeor value by zero will raise
a divide-by-zero exception", eller mer applikasjonsavhengig i
retning av "Three parents hird parent to a child record raises an
illegal-family-relationship exception". Unntaks-situasjonen *er*
der, uansett om den oppdages/flagges/handteres eller ikke.
Nufortiden tror G & Hv.mann at "to throw an exeception" ubetinget
er Det Det Heter, og forøsker å finne en oversettelse ut fra det.
Det er ikke mange år siden det het "to raise an exception" - da
var det "å heve et unntak" som ble foreslått som oversettelse.
Går du enda et stykke lenger tilbake var det ikke så mange som
programmerte i språk som hadde unntaksmekanismer, men for de som
gjorde det, kunne det hete "to cause an exception". Om dette er
tre distinkte, veldefinerte og ulike begreper kan man strides om,
men programmerings-teknisk er det stort sett nøkkelordet som skiller
dem, ikke betydningen. (Ulike språk kan ha ulike nyanseforskjeller
i semantikken, men det kan svært sjelden føres tilbake til *ordet*.)
Hvis "raise" refererer til det at unntakssituasjonen *oppstår*,
ikke til handteringen, er ikke "flagge" et beskrivende ord. Hvis
det refererer til identifisering av det faktum at noe ikke er
som det normalt burde være, er "flagge" ok.
(I noen kontekster, f.eks. noen språk, er det eksplisitt definert
at/om "exception" er knyttet til handteringen eller ikke, men det
skifter fra det ene språket/miljøet til det andre.)
En annen nyanse... Å "flagge" noe betyr i vanlig språkbruk at
man *ikke* handterer situasjonen, man *påpeker* den og overlater til
andre å ta initiativet for å ta den videre - du kan godt flagge et
problem uten at det fører til at det blir gjort noe med det.
I programmering menes som regel med "to raise an exception" at man
tar aktivit initiativ for å få aktivert handteringen. Det er ikke
helt heldig om man i programmering har en bruk av begrepet som
avviker *litt* fra vanlig tolking, men ikke nok til at man er
det bevisst. (F.eks. hvis en programmerer tar for gitt at flagging
av et unntak medfører aktivisering av en behandlingsrutine, mens
kunden, som ikke er datamann, antar at behandling kan, men slett
ikke behøver, iverksettes.)
Jon Haugsand:
> Følgende er brukt, og gir en ganske direkte oversettelse:
Jeg faller ikke helt for argumentet "ganske direkte oversettelse"
når det ikke faller sammen med tradisjonell norsk språkbruk.
> Throw an exception - Kaste et unntak
Jeg vet ikke om noen annen (dvs. utenom programmering) situasjon der
noen ville finne på å "kaste" et unntak! Folk som ikke kjenner det
opprinnelige uttrykket kan svært lett tolke "kaste" i betydningen
"forkaste", dvs. *ignoerere* unntakssituasjonen. Det er *meget* uheldig.
(Og hva skal man med oversettelser, hvis leseren må kjenne det
opprinnelige uttrykket for å skjønne hva det er snakk om?)
Flytter vi over til ikke-datatekniske forhold, hva er det vi da sier?
Hvis du kjører av veien, *forårsaker* du en unntakssituasjon, eller
det *oppstår* et unntak; dette refererer til at noe særskilt *skjer*.
Når du setter opp varseltrekanten for å *identifisere* situasjonen
kan du gjerne kalle det å "flagge" den - eller gjerne "identifisere"
den, for min del.
Å få "noen" (dvs. den relevante unntaksrutine) til å handtere
situasjonen ville vi på "vanlig norsk" kalle å "varsle" om unntaket
> Catch an exception - Fange et unntak
... og på vanlig norsk ville vi kalle det å "handtere" situasjonen.
Håkon Nilsen:
> Hvis du synes at kasting av unntak er uforståelig, har du kanskje ikke
> jobbet med slike egenskaper i programmeringsspråk før.
Unnskyld??
Stammespråk kan være vel å bra for å hindre at utenforstående skal
forstå hva De Invidde snakker om, men da får vi kalle det oversetting
til stammespråk, og ikke oversetting til norsk!
Selv om "kasting" og "unntak" syntaktisk sett er kjente norske ord,
har de også en kjent semantikk. Hvis du definerer en helt anenn semantikk
for ordet, har du definert et helt nytt ord, hittil ukjent i norsk, og
det syntaktisk sammenfallet med et eksisterende ord er ganske tilfeldig -
og tildels forstyrrende (f.eks. at "kaste" kan assosieres med "forkaste").
Skal vi ha et stammespråk, kan det like gjerne være engelsk.
jb
Jon Haugsand
> > Følgende er brukt, og gir en ganske direkte oversettelse:
>
> Jeg faller ikke helt for argumentet "ganske direkte oversettelse"
> når det ikke faller sammen med tradisjonell norsk språkbruk.
Det er ikke noe argument, det er en gjengivelse av fakta. Ikke
tillegg meg meninger jeg ikke har.
>
> > Throw an exception - Kaste et unntak
>
> Jeg vet ikke om noen annen (dvs. utenom programmering) situasjon der
> noen ville finne på å "kaste" et unntak! Folk som ikke kjenner det
> opprinnelige uttrykket kan svært lett tolke "kaste" i betydningen
> "forkaste", dvs. *ignoerere* unntakssituasjonen. Det er *meget* uheldig.
> (Og hva skal man med oversettelser, hvis leseren må kjenne det
> opprinnelige uttrykket for å skjønne hva det er snakk om?)
Jeg er enig i at det ikke er noen god oversettelse, og jeg har ikke
tenkt å forsvare den som sådan.
Men din argumentasjon henger ikke sammen. Å forstå et ord eller et
uttrykk betyr at du må få det definert og forklart, ikke at du skal
forstå det ved bare å lese det. Særlig tekniske uttrykk krever at du
faktisk setter deg inn i temaet. Det høres ut på deg at man skal
forstå "kaste et unntak" ved bare å se på ordene. Slik er det
iallfall ikke i mitt fagfelt fra før, og det kommer det heller ikke
til å bli.
> > Hvis du synes at kasting av unntak er uforståelig, har du kanskje ikke
> > jobbet med slike egenskaper i programmeringsspråk før.
>
> Unnskyld??
>
> Stammespråk kan være vel å bra for å hindre at utenforstående skal
> forstå hva De Invidde snakker om, men da får vi kalle det oversetting
> til stammespråk, og ikke oversetting til norsk!
Her begår du en annen typisk feil. "Throw/catch an exception" er ikke
"stammespråk" det er teknisk fagspråk, og det er programmerere som
bruker det. Eller mener du at man skal begynne å skrive fagbøker i
programmering beregnet på personer som ikke driver programmering?
Espen Vestre
> bruker det. Eller mener du at man skal begynne å skrive fagbøker i
> programmering beregnet på personer som ikke driver programmering?
Dette minner meg om hendelsen for en 20 års tid siden da forfatterne
av IN-110-læreboka (tror jeg det var) ble beæret med medlemskap i
dusteforbundet pga. definisjonen "En skog er en mengde trær" ;-)
--
(espen)
Jon Haugsand
Ole-Johan Dahl.
Joachim Lous
> Bjørn Brox:
>
>> Ordet signal kan vel brukes?
>> Sende ett signal.
"To signal" betyr allerede noe annet i konteksten, og "å sende et
signal" bør forbeholdes det.
>> Flagge ett unntak?
"To flag something" betyr allerede noe annet i konteksten, og "å
flagge noe" bør forbeholdes det.
Men du er nok inne på noe med at det er fysisk flaggheising som
i bunn og grunn ligger bak valget av "raise" slik det brukes om
exception og events. Da burde vel det naturlige være å oversette
det med "heise", som i "å heise flagg"?
>> Throw an exception - Kaste et unntak
>
> Jeg vet ikke om noen annen (dvs. utenom programmering) situasjon der
> noen ville finne på å "kaste" et unntak! Folk som ikke kjenner det
> opprinnelige uttrykket kan svært lett tolke "kaste" i betydningen
> "forkaste", dvs. *ignoerere* unntakssituasjonen. Det er *meget* uheldig.
Tror den engelske bruken er modellert etter uttrykk som "to throw a
fit" o.l. "Kaste" brukes jo ikke slik på norsk, så det blir litt rart
semantisk. Samtidig er det vanskelig å finne noe som man lettere kan
forstå uten å ha hørt oversettelsen før...
> (Og hva skal man med oversettelser, hvis leseren må kjenne det
> opprinnelige uttrykket for å skjønne hva det er snakk om?)
Holde et minstemål av språklig stil.
Det er da ingen andre som trenger disse ordene i uansett?
> Flytter vi over til ikke-datatekniske forhold, hva er det vi da sier?
> Hvis du kjører av veien, *forårsaker* du en unntakssituasjon, eller
> det *oppstår* et unntak; dette refererer til at noe særskilt *skjer*.
>
> Når du setter opp varseltrekanten for å *identifisere* situasjonen
> kan du gjerne kalle det å "flagge" den - eller gjerne "identifisere"
> den, for min del.
>
> Å få "noen" (dvs. den relevante unntaksrutine) til å handtere
> situasjonen ville vi på "vanlig norsk" kalle å "varsle" om unntaket
Hva med "innføre", som i "unntakstilstand"?
Eller "sende", selvsagt.
>> Catch an exception - Fange et unntak
>
> ... og på vanlig norsk ville vi kalle det å "handtere" situasjonen.
"Fange opp" burde vel være et greit kompromiss?
> Stammespråk kan være vel å bra for å hindre at utenforstående skal
> forstå hva De Invidde snakker om, men da får vi kalle det oversetting
> til stammespråk, og ikke oversetting til norsk!
Stammespråk blir det uansett, så lenge man må kunne programmere for å i
det hele tatt forstå begrepene disse ordene uttrykker. Derfor synes jeg
at programmerernes evne til å forstå oversettelsene umiddelbart når de
møter dem, og sjansene for at de vil bruke dem, _er_ helt sentrale
kritereier når man skal velge oversettelser her.
--
+-------------------------------------------------------------------------+
|Barn leker. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Geir Harris Hedemark
> Synes det er vel så idiotisk å snakke om å traue og kætsje eksæpsjæns i
> dagligtale. Språket vårt er norsk tross alt, og om jeg snakker om å kaste
> et unntak, forstår alle noenlunde erfarne programmerere meg. På samme måte
Nei, språket vårt er tross alt ikke norsk.
En som driver med programmering profesjonelt vil være nødt til å
forholde seg til et bakgrunnsmateriale som for det meste er
engelsk. Unntaket er introduksjonsbøker som i noen tilfelle finnes på
norsk.
Det gjelder også alle de andre profesjonelle programmererne rundt ham.
Språk er noe vi bruker for å kommunisere. Det å konstruere norske
uttrykk for noe vil utelukkende gjøre det vanskeligere for norske
programmerere å fungere ute i verden. Norge er på mange måter et
lilleputtland når det gjelder programmering. Skal vi henge med er vi
absolutt nødt til å forholde oss til resten av verden. Det gjør vi
ikke ved å distansere begrepsapparatet til samtlige norske
programmerere fra det som brukes i resten av verden. Skal norske
programmerere kunne konkurrere med det høye kostnadsnivået vi har må
vi være _enda_bedre_ enn resten av verden på alt de gjør, og helst ha
noen unike ting bare vi er flinke på. Dersom vi skal jage etter resten
av verden for å konvertere vårt eget begrepsapparat vil vi aldri få
overskudd til å bli best - vi vil hele tiden jage etter.
Jeg synes også det er meningsløst å konstruere norske begrep for å
tekkes ikkeprofesjonelle programmerere eller ikkeprogrammerere. Det
gir unøyaktigheter og feilkilder (eksempel: et lyst hode har oversatt
"virtual and actual parameters" med "virtuelle og aktuelle
parametre". Menneske er sikkert flink i norsk, men har tydeligvis
manglende kontroll på hva som menes med begrepet - eller engelsk) som
er unødvendige - de aller fleste i bransjen forholder seg uansett til
de engelske faguttrykkene. De har ikke noe valg.
Derfor mener jeg hele diskusjonen ikke er et meningsfylt sløseri med
tid.
Geir
Frode Vatvedt Fjeld
> Stammespråk blir det uansett, så lenge man må kunne programmere for
> å i det hele tatt forstå begrepene disse ordene uttrykker. Derfor
> synes jeg at programmerernes evne til å forstå oversettelsene
> umiddelbart når de møter dem, og sjansene for at de vil bruke dem,
> _er_ helt sentrale kritereier når man skal velge oversettelser her.
Jeg tror det er fullstendig urealistisk å kunne lage slike norske
begreper slik at de kan forstås uten videre. Bl.a fordi det er uklart
om A) begrepene bør speile de engelske eller B) om de kun bør forholde
seg til det faktiske begrepet og norske vendinger som kan tenkes å
passe situasjonen. A og B er så vidt jeg kan se svært forskjellige,
fordi de engelske ordene ofte er meget vage og kontekstavhengige, slik
at det er usannsynlig at strategi B vil gi ord med en-til-en-forhold
til de engelske ordene. (F.eks når jeg snakker om exceptions og slikt
på engelsk forholder jeg meg som oftest til terminologien i
CL-standarden, som skiller seg en del fra andre kontekster på dette
området.) Mens strategi A vil være enklere å forholde seg til f.eks
som oversetter, men forutsetter klart en ordbokstabell. "Norsk
Dataordbok" har vel vist hvor vellykket den strategien (ikke) er.
--
Frode Vatvedt Fjeld
Jon Haugsand
> >> Throw an exception - Kaste et unntak
> >
> > Jeg vet ikke om noen annen (dvs. utenom programmering) situasjon der
> > noen ville finne på å "kaste" et unntak! Folk som ikke kjenner det
> > opprinnelige uttrykket kan svært lett tolke "kaste" i betydningen
> > "forkaste", dvs. *ignoerere* unntakssituasjonen. Det er *meget* uheldig.
>
> Tror den engelske bruken er modellert etter uttrykk som "to throw a
> fit" o.l. "Kaste" brukes jo ikke slik på norsk, så det blir litt rart
> semantisk. Samtidig er det vanskelig å finne noe som man lettere kan
> forstå uten å ha hørt oversettelsen før...
Hmm, vi har jo "kaste terninger", "kaste seg inn i kampen", "kaste
seg" (i poker) og "kaste skygge", hvilket betyr at det er mange
abstrakte betydninger av "å kaste" hvilket gjør innføringen av en ny
variant litt enklere.
Men kanskje ikke.
Joachim Lous
> Joachim Lous <address...@example.net> writes:
>
>> Stammespråk blir det uansett, så lenge man må kunne programmere for
>> å i det hele tatt forstå begrepene disse ordene uttrykker. Derfor
>> synes jeg at programmerernes evne til å forstå oversettelsene
>> umiddelbart når de møter dem, og sjansene for at de vil bruke dem,
>> _er_ helt sentrale kritereier når man skal velge oversettelser her.
>
> Jeg tror det er fullstendig urealistisk å kunne lage slike norske
> begreper slik at de kan forstås uten videre. Bl.a fordi det er uklart
> om A) begrepene bør speile de engelske eller B) om de kun bør forholde
> seg til det faktiske begrepet og norske vendinger som kan tenkes å
> passe situasjonen.
Jeg synes man bør velge i hvert tilfelle. At en programmerer uten alt
for mye betenkning bør kunne gjette hvilket begrep det er snak om bør
være _ett_ av kriteriene. Om det så skjer via makeansme A eller B er
underordnet.
--
+-------------------------------------------------------------------------+
|Brett ut og bøy helt tilbake. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Joachim Lous
> et lyst hode har oversatt
> "virtual and actual parameters" med "virtuelle og aktuelle
> parametre". Menneske er sikkert flink i norsk,
Synes ikke det virker slik; det hører mer ut som nettopp en typisk
ingeniør-oversettelse der man _ikke_ tar hensyn til norsken.
Men jeg er enig i at krempefornorskning kan gå for langt. Samtidig er
det lite som høres så dumt ut som folk som på død og liv skal bruke
engelske ord for de mest dagligdagse ting, for liksom å høres mer
"profesjonell" ut.
--
+-------------------------------------------------------------------------+
|Uautorisert reproduksjon eller offentlig fremføring er strengt forbudt. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Geir Harris Hedemark
> det lite som høres så dumt ut som folk som på død og liv skal bruke
> engelske ord for de mest dagligdagse ting, for liksom å høres mer
> "profesjonell" ut.
Jeg synes det er helt ok å la slike mennesker tone flagg så tidlig som
overhodet mulig.
Du kan forsåvidt også hive på folk som bruker litt for mange TBF og
MTBF-er i den gruppa.
Geir
Leif Roar Moldskred
> Nufortiden tror G & Hv.mann at "to throw an exeception" ubetinget
> er Det Det Heter, og forøsker å finne en oversettelse ut fra det.
> Det er ikke mange år siden det het "to raise an exception" - da
> var det "å heve et unntak" som ble foreslått som oversettelse.
Sjølv ville eg nok ha lest det i tydinga "å oppheve eit unntak" på
same måte som "å heve eit vedtak" betyr å oppheve det. Ein kunne
kanskje ha brukt "å fremme eit unntak"?
--
Leif Roar
Frode Vatvedt Fjeld
> Jeg synes man bør velge i hvert tilfelle. At en programmerer uten
> alt for mye betenkning bør kunne gjette hvilket begrep det er snak
> om bør være _ett_ av kriteriene. Om det så skjer via makeansme A
> eller B er underordnet.
Men jeg vil tro at man som oftest ønsker å unngå en situasjon hvor man
trenger å gjette overhodet. Man må kunne være sikker, og hvis man
eksplistt må finne en binding fra det norske ordet til et engelsk for
hver kontekst, er vel mye av poenget borte. Jeg mener, du kan si at
umiddelbar forståelse bare er et av flere kriterier, men jeg påstår at
dette ene kriteriet ikke lar seg oppfylle i mange tilfeller.
--
Frode Vatvedt Fjeld
Kjetil Torgrim Homme
>
> Nufortiden tror G & Hv.mann at "to throw an exeception" ubetinget
> er Det Det Heter, og forøsker å finne en oversettelse ut fra det.
> Det er ikke mange år siden det het "to raise an exception" - da
> var det "å heve et unntak" som ble foreslått som oversettelse.
> Går du enda et stykke lenger tilbake var det ikke så mange som
> programmerte i språk som hadde unntaksmekanismer, men for de som
> gjorde det, kunne det hete "to cause an exception". Om dette er
> tre distinkte, veldefinerte og ulike begreper kan man strides om,
> men programmerings-teknisk er det stort sett nøkkelordet som
> skiller dem, ikke betydningen.
dette synest eg er ein knakande god observasjon.
throw: C++, Java, C#
raise: Ada, SQL, Python, Ruby
cause: maskinnær programmering, generell term
mitt forslag er "forårsake", som kan oppfattast både passivt og
aktivt.
> Jeg vet ikke om noen annen (dvs. utenom programmering) situasjon
> der noen ville finne på å "kaste" et unntak! Folk som ikke kjenner
> det opprinnelige uttrykket kan svært lett tolke "kaste" i
> betydningen "forkaste", dvs. *ignoerere* unntakssituasjonen. Det
> er *meget* uheldig.
så einig, så einig.
> Skal vi ha et stammespråk, kan det like gjerne være engelsk.
igjen einig. viss ein ikkje finn gode norske ord, er det betre å
behalde den engelske originalen, stavemåte inkludert.
--
Kjetil T.
Alf P. Steinbach
>
> dette synest eg er ein knakande god observasjon.
>
> throw: C++, Java, C#
> raise: Ada, SQL, Python, Ruby
> cause: maskinnær programmering, generell term
Vi som en gang i tiden programmerte MS-DOS og 16-bits Windows brukte
svært ofte (faktisk hver gang en OS- eller BIOS-funksjon skulle anropes)
å iverksette unntaksbehandling, som på x86-prosessorene er samme
mekanisme som generelle avbrudd. Avbruddstype (unntak) 21h var MS-DOS,
og 3 var og er brukt til avbruddspunkt for debugging. Disse to
anvendelsene viser etter min oppfatning at unntakshåndtering på
maskinkodenivået er noe helt annet og brukes til helt andre ting enn
unntakshåndtering i høyere nivå språk (selv om maskinkodenivå unntak
også brukes i bunnen av høyere nivå språks unntaksmekanismer). Derfor
blir etter min oppfatning det å blande terminologi fra disse
anvendelsene feil, og jeg har forøvrig ikke hørt ordet "cause" brukt.
> mitt forslag er "forårsake", som kan oppfattast både passivt og
> aktivt.
Det trengs ingen ny oversetting. Jon Haugsand har allerede gitt en grei
oppsummering av eksisterende norsk språkbruk. Jeg siterer ham:
Throw an exception - Kaste et unntak
Catch an exception - Fange et unntak
Exception handling - Unntakshåndtering
Det eneste problemet er det siste, "håndtering", som er flertydig både
på engelsk og norsk. Nemlig, er det snakk om den generelle mekanismen
(ja det kan det være) eller det som gjøres når et unntak er fanget (ja
det kan det være) eller for eksempel design og kodingsteknikker som
støtter bruk av unntak i programmet (ja det kan det være).
> igjen einig. viss ein ikkje finn gode norske ord, er det betre å
> behalde den engelske originalen, stavemåte inkludert.
Inntil man vet hvordan "renault" uttales, si "re-na-ult". ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Markus B. Krüger
> * Kjetil Torgrim Homme:
> >
> > dette synest eg er ein knakande god observasjon.
> >
> > throw: C++, Java, C#
> > raise: Ada, SQL, Python, Ruby
> > cause: maskinnær programmering, generell term
>
> Vi som en gang i tiden programmerte MS-DOS og 16-bits Windows brukte
> svært ofte (faktisk hver gang en OS- eller BIOS-funksjon skulle
> anropes) å iverksette unntaksbehandling, som på x86-prosessorene er
> samme mekanisme som generelle avbrudd. Avbruddstype (unntak) 21h
> var MS-DOS, og 3 var og er brukt til avbruddspunkt for debugging.
Den gang jeg holdt på med MS-DOS-programmering, kan jeg ikke huske at
avbrudd noensinne ble likestilt med eller referert til som unntak.
Men det kan være hukommelsen min svikter; uansett varierte
terminologien sikkert fra miljø til miljø. Inntrykket mitt var at det
finnes maskinvareoperasjoner (f.eks. divisjon på 0) som forårsaker
unntak, og at unntakene igjen utløser et avbrudd, men at det er mange
andre måter å utløse et avbrudd på (maskinkodeinstruksen "int",
maskinvareutløste avbrudd fra eksterne enheter).
> Disse to anvendelsene viser etter min oppfatning at
> unntakshåndtering på maskinkodenivået er noe helt annet og brukes
> til helt andre ting enn unntakshåndtering i høyere nivå språk (selv
> om maskinkodenivå unntak også brukes i bunnen av høyere nivå språks
> unntaksmekanismer).
Er det, eller var det, vanlig å implementere unntakshåndtering i
programmeringsspråk med avbrudd? Jeg innbilte meg at man som regel
brukte andre mekanismer, men jeg har ikke lest nok kompilatorkildekode
eller disassembly til å vite om denne magefølelsen stemmer -- kan noen
utdype?
--
,------------------- Markus Bjartveit Krüger ---------------------.
' `
` E-mail: mar...@pvv.org WWW: http://www.pvv.org/~markusk/ '
)-------------------------------------------------------------------(
Trond Norbye
>
> Synes det er vel så idiotisk å snakke om å traue og kætsje eksæpsjæns i
> dagligtale.
I min dagligtale snakker jeg stort sett på et høyere nivå. Når man
kommer til konkrete problemer går det stort sett på mail/irc/msn o.l.
Men hvis jeg snakker om det, ja da er det throw og catch.. Det er da
tross alt programmerere jeg snakker med...
> Språket vårt er norsk tross alt, og om jeg snakker om å kaste
> et unntak, forstår alle noenlunde erfarne programmerere meg. På samme måte
> som det er vanlig å si Java-bønner istedet Java-beans, eller for den saks
> skyld epost istedetfor email.
Hmm.. lukter jeg at du også skriver alle kommentarene i koden dine på
norsk? En del av oss har ett tett samarbeid med utenlandske selskap, og
da er det veldig mye enklere om man har standardisert seg på ett språk...
> Hvis du synes at kasting av unntak er uforståelig, har du kanskje ikke
> jobbet med slike egenskaper i programmeringsspråk før.
Synes ikke det er uforståelig, men ser ikke at det er mer forståelig en
throw an exception. Men jeg har _STORE_ problemer med å forstå _HVA_ man
skal bruke det til... Du snakker vel ikke om "kasting av unntak" til
mora di? nei.. du snakker med programmerere, og de vet utmerket godt hva
throw an exception betyr... det er jo tross alt det de leser om i bøkene
sine, finner i hjelpesystemene til utviklingsverktøyene sine etc...
(hmm hva kaller man da en IDE på norsk? integrert utviklingsmiljø? IUM?)
Trond
Alf P. Steinbach
> * Alf P. Steinbach:
>
> > * Kjetil Torgrim Homme:
> > >
> > > dette synest eg er ein knakande god observasjon.
> > >
> > > throw: C++, Java, C#
> > > raise: Ada, SQL, Python, Ruby
> > > cause: maskinnær programmering, generell term
> >
> > Vi som en gang i tiden programmerte MS-DOS og 16-bits Windows brukte
> > svært ofte (faktisk hver gang en OS- eller BIOS-funksjon skulle
> > anropes) å iverksette unntaksbehandling, som på x86-prosessorene er
> > samme mekanisme som generelle avbrudd. Avbruddstype (unntak) 21h
> > var MS-DOS, og 3 var og er brukt til avbruddspunkt for debugging.
>
> Den gang jeg holdt på med MS-DOS-programmering, kan jeg ikke huske at
> avbrudd noensinne ble likestilt med eller referert til som unntak.
Det er fullt mulig å bruke ting uten å kjenne til hvordan de fungerer
på innsiden, ja. ;-)
Kanskje det enkleste for deg er å sjekke opp hvordan du koder og
installerer en x86 unntaksrutine kontra en avbruddsrutine.
Store overraskelse (?): der er ingen forskjell på maskinkodenivået.
> Men det kan være hukommelsen min svikter; uansett varierte
> terminologien sikkert fra miljø til miljø.
Sikkert.
Felles utgangspunkt var dog Intel sin terminologi, siden de laget
prosessoren.
> Inntrykket mitt var at det
> finnes maskinvareoperasjoner (f.eks. divisjon på 0) som forårsaker
> unntak, og at unntakene igjen utløser et avbrudd,
Nei. x86 har i likhet med mange andre prosessorer en generell unntaks-
mekanisme som også brukes til avbrudd. Eller en generell avbrudds-
mekanisme som også brukes til unntak, avhengig av kontekst & synspunkt.
> men at det er mange
> andre måter å utløse et avbrudd på (maskinkodeinstruksen "int",
> maskinvareutløste avbrudd fra eksterne enheter).
Som sagt.
> > Disse to anvendelsene viser etter min oppfatning at
> > unntakshåndtering på maskinkodenivået er noe helt annet og brukes
> > til helt andre ting enn unntakshåndtering i høyere nivå språk (selv
> > om maskinkodenivå unntak også brukes i bunnen av høyere nivå språks
> > unntaksmekanismer).
>
> Er det, eller var det, vanlig å implementere unntakshåndtering i
> programmeringsspråk med avbrudd?
Forutsetter at du mener "er det vanlig å bruke prosessorens
unntaks/avbrudds-mekanisme til å implementere unntakshåndtering i for
eksempel C++?", siden "programmeringsspråk med avbrudd" ikke parser.
Ja og nei, avhengig av hvordan du definerer "vanlig".
SEH unntakshåndteringen i x86 Windows er basert på den fysiske
unntakshåndteringen/avbruddshåndteringen i prosessoren, og Visual C++
sin unntakshåndtering er i sin tur bygd på toppen av SEH. Det ville
for eksempel blitt for ineffektivt å legge sjekking av nullpeker på
enhver peker dereferering, eller sjekking av divisjon på null etc. på
enhver aritmetisk operasjon. Men for en mekanisme som spesifikt er
designet for å _ikke_ behøve å fange opp slikt, som for eksempel C++,kan
man mer fritt bruke andre og potensielt mer effektive mekanismer.
> Jeg innbilte meg at man som regel
> brukte andre mekanismer, men jeg har ikke lest nok kompilatorkildekode
> eller disassembly til å vite om denne magefølelsen stemmer -- kan noen
> utdype?
Andre mekanismer blir brukt, med en avveining mellom funksjonalitet og
hastighet blant annet som forklart ovenfor.
Markus B. Krüger
> * Markus B. Krüger:
> > * Alf P. Steinbach:
> >
> > > Vi som en gang i tiden programmerte MS-DOS og 16-bits Windows
> > > brukte svært ofte (faktisk hver gang en OS- eller BIOS-funksjon
> > > skulle anropes) å iverksette unntaksbehandling, som på
> > > x86-prosessorene er samme mekanisme som generelle avbrudd.
> > > Avbruddstype (unntak) 21h var MS-DOS, og 3 var og er brukt til
> > > avbruddspunkt for debugging.
> >
> > Den gang jeg holdt på med MS-DOS-programmering, kan jeg ikke huske
> > at avbrudd noensinne ble likestilt med eller referert til som
> > unntak.
>
> Det er fullt mulig å bruke ting uten å kjenne til hvordan de
> fungerer på innsiden, ja. ;-)
>
> Kanskje det enkleste for deg er å sjekke opp hvordan du koder og
> installerer en x86 unntaksrutine kontra en avbruddsrutine.
>
> Store overraskelse (?): der er ingen forskjell på maskinkodenivået.
Jeg er ikke kjent med begrepet "x86 unntaksrutine", men jeg mistenker
at grunnen til dette er at unntaksrutiner og avbruddsrutiner er helt
identiske for en programmerer, det eneste av betydning er hvilken post
i IDTen rutinen installeres på (og at man vet hva som kan utløse
rutinen!). Mulig mistanken min er feil; se utdyping lenger nede i
innlegget for begrunnelse.
> > Inntrykket mitt var at det finnes maskinvareoperasjoner
> > (f.eks. divisjon på 0) som forårsaker unntak, og at unntakene
> > igjen utløser et avbrudd,
>
> Nei. x86 har i likhet med mange andre prosessorer en generell unntaks-
> mekanisme som også brukes til avbrudd. Eller en generell avbrudds-
> mekanisme som også brukes til unntak, avhengig av kontekst & synspunkt.
Jeg har nå skummet gjennom kapittel 6 ("Procedure Calls, Interrupts,
and Exceptions") av "IA-32 Intel® Architecture Software Developers
Manual Volume 1: Basic Architecture" og kapitell 5 ("Interrupt and
Exception Handling") av "IA-32 Intel® Architecture Software Developers
Manual Volume 3: System Programming Guide" (tilgjengelig på
<http://developer.intel.com/design/pentium4/manuals/25366513.pdf> og
<http://developer.intel.com/design/pentium4/manuals/25366813.pdf>), og
det gjorde ting litt klarere. Selv om de skiller mellom avbrudd og
unntak, synes det ikke å være noen forskjell mellom avbrudds- og
unntaktsrutiner, og avbrudd og unntak deler samme "interrupt
descriptor table" (IDT) for oppslag. Selvfølgelig er det forskjellige
hendelser som utløser forskjellige rutiner i IDTen, men skillet mellom
hvilke hendelser som utløser hva synes ikke å følge noen inndeling
mellom avbrudd og unntak, og hvordan rutinene skrives og installeres
synes å være identisk for avbrudd og inntak.
Med andre ord ser det for meg ut som om hvorvidt noe er et unntak
eller et avbrudd ikke har noen betydning for den som skriver en rutine
på maskinkodenivå for å håndtere unntaket eller avbruddet. Dette kan
kanskje forklare hvorfor jeg ikke kan huske noe slikt skille.
> > > Disse to anvendelsene viser etter min oppfatning at
> > > unntakshåndtering på maskinkodenivået er noe helt annet og
> > > brukes til helt andre ting enn unntakshåndtering i høyere nivå
> > > språk (selv om maskinkodenivå unntak også brukes i bunnen av
> > > høyere nivå språks unntaksmekanismer).
> >
> > Er det, eller var det, vanlig å implementere unntakshåndtering i
> > programmeringsspråk med avbrudd?
>
> Forutsetter at du mener "er det vanlig å bruke prosessorens
> unntaks/avbrudds-mekanisme til å implementere unntakshåndtering i for
> eksempel C++?", siden "programmeringsspråk med avbrudd" ikke parser.
Parsinga går kanskje enklere med paranteser:
(implementere (unnntakshåndtering i programmeringsspråk) med avbrudd), ikke
(implementere unnntakshåndtering i (programmeringsspråk med avbrudd)).
Med andre ord, ja.
> Ja og nei, avhengig av hvordan du definerer "vanlig".
>
> SEH unntakshåndteringen i x86 Windows er basert på den fysiske
> unntakshåndteringen/avbruddshåndteringen i prosessoren, og Visual C++
> sin unntakshåndtering er i sin tur bygd på toppen av SEH.
Ok, så en "throw" kompilert av Visual C++ ender før eller siden opp i
maskinkoden "int"? Eller misforstår jeg?
Forøvrig har jeg sett folk beklage seg over at Visual C++ bruker samme
unntakshåndtering for feil på maskinnivå og på språknivå, siden det
medfører at "catch(...)" også fanger opp fataliteter som
segmenteringsfeil, der utvikleren ofte hadde ønsket seg en øyeblikket
avslutning med minnedump i stedet. Man kan kanskje kommer rundt dette
problemet ved å sørge for at alle unntak forårsaket av språket gjennom
"throw" arver fra en felles superklasse (f.eks. std::exception), slik
at man kan bytte ut alle "catch(...)" med "catch(std::exception e)"?
Kjetil Torgrim Homme
>
> * Kjetil Torgrim Homme:
> >
> > dette synest eg er ein knakande god observasjon.
> >
> > throw: C++, Java, C#
> > raise: Ada, SQL, Python, Ruby
> > cause: maskinnær programmering, generell term
>
> Vi som en gang i tiden programmerte MS-DOS og 16-bits Windows
> brukte svært ofte (faktisk hver gang en OS- eller BIOS-funksjon
> skulle anropes) å iverksette unntaksbehandling, som på
> Derfor blir etter min oppfatning det å blande terminologi fra
> disse anvendelsene feil, og jeg har forøvrig ikke hørt ordet
> "cause" brukt.
eg har aldri drive med programmering på DOS, og nemnte heller aldri
DOS, så dette er ein rein stråmann.
--
Kjetil T.
Frode Vatvedt Fjeld
> Inntrykket mitt var at det finnes maskinvareoperasjoner
> (f.eks. divisjon på 0) som forårsaker unntak, og at unntakene igjen
> utløser et avbrudd, men at det er mange andre måter å utløse et
> avbrudd på (maskinkodeinstruksen "int", maskinvareutløste avbrudd
> fra eksterne enheter).
Jeg mener at den eneste meningsfulle betydningen av "avbrudd"
("interrupt") er ekte signaler utenfra CPU-en, mao. fra tastaturet
eller liknende. I arkitekturer som x86 er dermed avbrudd en
undergruppe av unntak ("exceptions"). Dette til tross for at
x86-instruksjonen for å eksplisitt generere et unntak heter "int". Den
burde hete "exception" eller noe slikt.
> Er det, eller var det, vanlig å implementere unntakshåndtering i
> programmeringsspråk med avbrudd? Jeg innbilte meg at man som regel
> brukte andre mekanismer, men jeg har ikke lest nok
> kompilatorkildekode eller disassembly til å vite om denne
> magefølelsen stemmer -- kan noen utdype?
Man må skille mellom det å _detektere_ en unntakstilstand (uff.. er
det nok norske fagtermer nå? Jeg mener altså en programtilstand som
ifølge semantikken til programmeringsspråket skal resultere i et
unntak på dette abstraksjonsnivået) og det å _håndtere_ den. Hvis man
kan sørge for at CPU-en automatisk genererer et unntak i gitte
situasjoner, kan man bruke dette til å detektere unntakstilstander med
minimal ekstra kostnad. F.eks vil man uten videre få et
divisjon-med-null-unntak, mens man med litt fikling også kan sørge for
å få et unntak når man leser eller skriver en null-peker. Men selve
håndteringen av samme (på programmeringsspråknivå) er strengt tatt
helt uavhengig av dette.
--
Frode Vatvedt Fjeld
Alf P. Steinbach
> * Alf P. Steinbach:
> > * Markus B. Krüger:
> > > * Alf P. Steinbach:
> > >
> > > > Vi som en gang i tiden programmerte MS-DOS og 16-bits Windows
> > > > brukte svært ofte (faktisk hver gang en OS- eller BIOS-funksjon
> > > > skulle anropes) å iverksette unntaksbehandling, som på
> > > > x86-prosessorene er samme mekanisme som generelle avbrudd.
> > > > Avbruddstype (unntak) 21h var MS-DOS, og 3 var og er brukt til
> > > > avbruddspunkt for debugging.
> > >
> > > Den gang jeg holdt på med MS-DOS-programmering, kan jeg ikke huske
> > > at avbrudd noensinne ble likestilt med eller referert til som
> > > unntak.
> >
> > Det er fullt mulig å bruke ting uten å kjenne til hvordan de
> > fungerer på innsiden, ja. ;-)
> >
> > Kanskje det enkleste for deg er å sjekke opp hvordan du koder og
> > installerer en x86 unntaksrutine kontra en avbruddsrutine.
> >
> > Store overraskelse (?): der er ingen forskjell på maskinkodenivået.
>
> Jeg er ikke kjent med begrepet "x86 unntaksrutine", men jeg mistenker
> at grunnen til dette er at unntaksrutiner og avbruddsrutiner er helt
> identiske for en programmerer, det eneste av betydning er hvilken post
> i IDTen rutinen installeres på (og at man vet hva som kan utløse
> rutinen!).
Jepp.
> Jeg har nå skummet gjennom kapittel 6 ("Procedure Calls, Interrupts,
> and Exceptions") av "IA-32 Intel® Architecture Software Developers
> Manual Volume 1: Basic Architecture" og kapitell 5 ("Interrupt and
> Exception Handling") av "IA-32 Intel® Architecture Software Developers
> Manual Volume 3: System Programming Guide" (tilgjengelig på
> <http://developer.intel.com/design/pentium4/manuals/25366513.pdf> og
> <http://developer.intel.com/design/pentium4/manuals/25366813.pdf>), og
> det gjorde ting litt klarere. Selv om de skiller mellom avbrudd og
> unntak, synes det ikke å være noen forskjell mellom avbrudds- og
> unntaktsrutiner, og avbrudd og unntak deler samme "interrupt
> descriptor table" (IDT) for oppslag. Selvfølgelig er det forskjellige
> hendelser som utløser forskjellige rutiner i IDTen, men skillet mellom
> hvilke hendelser som utløser hva synes ikke å følge noen inndeling
> mellom avbrudd og unntak, og hvordan rutinene skrives og installeres
> synes å være identisk for avbrudd og inntak.
Wow! Jeg mente ikke å sende deg så langt ned på havdypet! Beklager.
Brady hadde så vidt jeg husker bra bøker om x86. Anbefales.
> Med andre ord ser det for meg ut som om hvorvidt noe er et unntak
> eller et avbrudd ikke har noen betydning for den som skriver en rutine
> på maskinkodenivå for å håndtere unntaket eller avbruddet.
Jepp.
> Dette kan
> kanskje forklare hvorfor jeg ikke kan huske noe slikt skille.
Siden jeg er pedantisk anlagt i njus-diskusjoner vil jeg gjerne påpeke
at innvendingen din mot min første posting tilsynelatende var motsatt,
> > > Den gang jeg holdt på med MS-DOS-programmering, kan jeg ikke huske
> > > at avbrudd noensinne ble likestilt med eller referert til som
> > > unntak.
Så, er det det ene eller det andre? ;-)
> Ok, så en "throw" kompilert av Visual C++ ender før eller siden opp i
> maskinkoden "int"? Eller misforstår jeg?
Tror ikke du misforstår men det der vet jeg ikke og gidder ikke å
sjekke. Det jeg vet er at i tidligere versjoner av Visual C++, og i
nyere når du skrur på støtte for SEH, så ender en "int"-instruksjon
typisk opp som et SEH unntak som igjen ender eller kan ende opp som et
normalt C++ unntak (unntak: "int 3" kan også ende opp som et debugger
avbruddspunkt). Det var blant annet et hovedproblem med "catch(...)".
En annen åpenbar binding mot x86 prosessorens unntak er listen av
"exception codes" du kan få i et SEH unntak, som korresponderer ganske
direkte med det som Intel definerer som x86 unntakstyper (vektorer i
unntaks/avbrudds-tabellen). Det skulle sletten ikke forundre meg om det
til og med er de samme numeriske verdiene, men det er interne detaljer.
> Forøvrig har jeg sett folk beklage seg over at Visual C++ bruker samme
> unntakshåndtering for feil på maskinnivå og på språknivå, siden det
> medfører at "catch(...)" også fanger opp fataliteter som
> segmenteringsfeil, der utvikleren ofte hadde ønsket seg en øyeblikket
> avslutning med minnedump i stedet. Man kan kanskje kommer rundt dette
> problemet ved å sørge for at alle unntak forårsaket av språket gjennom
> "throw" arver fra en felles superklasse (f.eks. std::exception), slik
> at man kan bytte ut alle "catch(...)" med "catch(std::exception e)"?
Jeg bruker å anbefale å utlede C++ unntaksklasser for presumptivt
opprettelige (fiksbare) kontraktsbrudd fra std::runtime_error, og alle
andre fra std::exception-treet utenom std::runtime_error. Poenget med
dét er at for eksempel std::bad_alloc og std::bad_exception vanligvis
ikke er unntak som du ønsker å fange opp på lavere anropsnivåer, som er
det samme problemet som med at tidligere Visual C++ sin "catch(...)"
fanget opp rent for mye. Med den konvensjonen jeg angir her er "catch(
std::runtime_error const& )" safe, så fremt konvensjonen overholdes.
Norsk ord for "safe"?
Frode Vatvedt Fjeld
> Ok, så en "throw" kompilert av Visual C++ ender før eller siden opp
> i maskinkoden "int"? Eller misforstår jeg?
Du misforstår. Instruksjonen "int" kan brukes til å si "nå har vi en
unntakstilstand!". En vanlig respons på dette kan være noe som
tilsvarer en "throw" på programmeringsspråksnivå. Det "throw" ender
opp som er vanligvis noe slikt som dette:
1. Let oppover stacken etter nærmeste sted X som kan håndtere
situasjonen.
2. Finn og utfør kode som må utføres før vi kan hoppe fra nåværende
kontekst til X. Dvs. automatiske destruktører (destructors) i
C++, prøv-til-slutt (try-finally) i Java, eller
beskytt-mot-utrulling (unwind-protects) i CL.
3. Flytt kontroll til X. Dvs. i det minste sett haugpekeren
(stack-pekeren) og programtelleren til tilsvarende X.
Kortversjonen er at "throw" koker ned til en "jmp".
> Forøvrig har jeg sett folk beklage seg over at Visual C++ bruker
> samme unntakshåndtering for feil på maskinnivå og på språknivå,
> siden det medfører at "catch(...)" også fanger opp fataliteter som
> segmenteringsfeil, der utvikleren ofte hadde ønsket seg en
> øyeblikket avslutning med minnedump i stedet. Man kan kanskje
> kommer rundt dette problemet ved å sørge for at alle unntak
> forårsaket av språket gjennom "throw" arver fra en felles
> superklasse (f.eks. std::exception), slik at man kan bytte ut alle
> "catch(...)" med "catch(std::exception e)"?
Det "man" ønsker seg, og som "man" forhåpentlig kommer til å oppdage
innen kanskje 20 år (med mindre utviklingen blir slik man iblant får
inntrykk av og faktisk begynner å gå bakover) er et
programmeringssystem som evner å ikke blande sammen handler-bind og
handler-case. Eller er så generelt hjernedødt at man kan komme på
tanken å _ønske_ seg en minnedump og prosessdød.
--
Frode Vatvedt Fjeld
Knut Forkalsrud
> Hmm.. lukter jeg at du også skriver alle kommentarene i koden dine
> på norsk? En del av oss har ett tett samarbeid med utenlandske
> selskap, og da er det veldig mye enklere om man har standardisert
> seg på ett språk...
Jeg tror noe av poenget her tidligere var at begrepene er de samme i
mange forskjellig språk, og utfordringen var å finne gode norske navn
på dem. Så snart man legger til kommentarer i kildekoden har man
allerede innført flere språk. Programmerringsspråket (Java, LISP,
C++, etc.) er også et språk. Det er strengt definert med sin egen
gramatikk. Kommentarene i kildekoden kan være en salig blanding av
andre programmersingsspråk, engelsk og norsk. Når en refererer til
spesifikke ting i kildekoden er det greit å bruke ord og uttrykk
direkte fra programmeringsspråket. Jeg oppfatter kommentarer som
sitater/anførsler som hjelper til å gi mening der det er problematisk
å uttrykke seg innenfor programerringsspråket.
Ofte sitter man ikke med nesa 2 cm fra skjermen og gransker kildekode.
Man tar et par skritt tilbake og beskriver systemet på høyere nivå,
uavhengig av programmeringsspråket. Dermed begynner det å bli en
smule kunstig å låne ord fra enkelte programmeringsspråk for å fylle
begrep man mangler i norsk.
Før jeg glemmer det, Intel's x86 mikroprosessor var ikke av de mest
sofistikerte med hensyn på avbrudds-/unntakshåndtering. Jeg har mer
erfaring fra Intel's 960 serie mikroprosessorer, der manualen hadde et
eget kapittel om "Faults" og "fault handlers", som hadde samme
betydning som det som tidligere har vært beskrevet som "exceptions".
Tydeligvis vingler også Intel i navngivningen på engelsk. Jeg vil
også passe på å påpeke at avbrudd ("interrupts") ikke er det samme som
feil ("faults"). Deling på 0 er en feil. Skriving til adresser rundt
0 er også en feil. Å betjene innkommende nettverkstraffikk eller
brukerens tastetrykk er sjelden noe "unntak". Det er helt vanlig
operasjon, men det haster, slik at programflyten avbrytes midlertidig
for å gjøre jobben. De fleste moderne operativsystemer (MSDOS er
ingen målestokk) holder styr på mange prosesser/tråder samtidig.
"Tingen" som holder orden på hvilke tråder som får kjøre når er på
engelsk kalt "scheduler". Jeg kjenner ikke til noe
programmeringsspråk som har dette begrepet, og har ikke hørt noen god
norsk oversettele. I min gamle jobb kom vi ikke opp med noe bedre enn
å kalle det "fordeleren", i betydningen den som fordeler prosessor-tid
til trådene. Alternative forslag mottas med takk.
For å komme tilbake til det aktuelle begrepet "exception handling".
Dette brukes for å håndtere noe eksepsjonelt. Jeg synes "unntak" er
det beste forslaget så langt. Et alternativ til kaste/heve/heise kan
være "erklære", som i "erklære et unntak". "Håndtere" er nok bedre
enn "fange" (for catch). Begrepet bør i alle fall finnes på norsk.
-Knut
Joachim Lous
> Er det, eller var det, vanlig å implementere unntakshåndtering i
> programmeringsspråk med avbrudd?
Hele MS-DOS var implementert som avbrudd. Om det var en vanlig måte å
gjøre ting på i den æraen vet jeg ikke, men det fantes i hvert fall
andre OSer som hadde ekte OS-kall og signaler og slikt, så det kan ikke
ha vært enerådende. I dag er det i hvert fall ikke vanlig at
applikasjoner flest overhodet forholder seg til avbrudd.
--
+-------------------------------------------------------------------------+
|Må ikke punkteres eller brennes, heller ikke etter tømming. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Joachim Lous
> Et alternativ til kaste/heve/heise kan
> være "erklære", som i "erklære et unntak".
Glimrende! Akkurat det begrepet jeg famlet etter, med akkurat de rette
assosiasjonene. Signaliserer at det er noe man _bestemmer_ seg for å
gjøre, i motsetning til "forårsake" som høres ut som det betyr "cause",
som igjen ikke er det samme som "throw"/"raise".
Muligens en forvirringsfare at i mange tilfeller er
"erklære"=="declare" mens "declare"!="raise". Men datafolket sier jo
som regel "deklarere" og ikke "erklære" om å definere variable osv
(forøvrig med dekning i radisjonen, jf. "tolldeklarasjon"), så det
burde gå bra.
--
+-------------------------------------------------------------------------+
|Oppbevares utilgjengelig for barn. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Markus B. Krüger
> * Markus B. Krüger:
> > * Alf P. Steinbach:
> > > * Markus B. Krüger:
> >
> > Med andre ord ser det for meg ut som om hvorvidt noe er et unntak
> > eller et avbrudd ikke har noen betydning for den som skriver en
> > rutine på maskinkodenivå for å håndtere unntaket eller avbruddet.
> > Dette kan kanskje forklare hvorfor jeg ikke kan huske noe slikt
> > skille.
>
> Siden jeg er pedantisk anlagt i njus-diskusjoner vil jeg gjerne påpeke
> at innvendingen din mot min første posting tilsynelatende var motsatt,
>
> > > > Den gang jeg holdt på med MS-DOS-programmering, kan jeg ikke
> > > > huske at avbrudd noensinne ble likestilt med eller referert
> > > > til som unntak.
>
> Så, er det det ene eller det andre? ;-)
Jeg kunne ikke huske at begrepet "unntak" ble brukt om noe som helst
på assembly-nivå. Jeg ser nå at Intel brukte dette begrepet, derav
forklaringen min over: jeg tror grunnen til at jeg ikke husker eller
aldri fikk med meg unntak (igjen, på assembly-nivå), eller skillet
mellom unntak og avbrudd, fra MS-DOS-dagene, fordi det fra
programmererens synspunkt ikke *var* noe skille mellom dem, og at det
dermed ikke var noen grunn til å bruke to begreper der det holdt med
ett.
> > Ok, så en "throw" kompilert av Visual C++ ender før eller siden
> > opp i maskinkoden "int"? Eller misforstår jeg?
>
> Tror ikke du misforstår men det der vet jeg ikke og gidder ikke å
> sjekke.
Vel, det var egentlig det jeg bet meg merke i. Du skrev i
<408e95e9....@news.individual.net>:
Disse to anvendelsene viser etter min oppfatning at
unntakshåndtering på maskinkodenivået er noe helt annet og brukes
til helt andre ting enn unntakshåndtering i høyere nivå språk (selv
om maskinkodenivå unntak også brukes i bunnen av høyere nivå språks
unntaksmekanismer).
Kommentaren i paranteser mener jeg er feil: avbrudds- og
unntaksrutinene for x86-prosessoren som installeres av Windows
resulterer i kall til samme mekanismer som unntak i C++, men det betyr
ikke at C++ bruker maskinkodenivå unntak, med mindre du med
maskinkodenivå unntak mener SEH og ikke unntak slik Intel definerer
dem.
Frode Vatvedt Fjeld skriver forøvrig i
<2hd65th...@vserver.cs.uit.no> at maskinkoden "int" *ikke* brukes
i implementasjonen av C++-konstruksjonen "throw".
Markus B. Krüger
> mar...@pvv.org (Markus B. Krüger) writes:
>
> > Ok, så en "throw" kompilert av Visual C++ ender før eller siden opp
> > i maskinkoden "int"? Eller misforstår jeg?
>
> Du misforstår.
Nei, jeg misforsto ikke Alf, men Alfs påstand var feil. :-)
> [...] Kortversjonen er at "throw" koker ned til en "jmp".
Dette (og forklaringen jeg klippet fra sitatet over) var hvordan jeg
hadde inntrykket av at unntak typisk var implementert. Takk for
bekreftelsen. Om noen har gode referanser til detaljert dokumentasjon
av unntaksimplementasjoner, er jeg interessert; alltids artig å grave
seg ned i maskineriet.
> > Forøvrig har jeg sett folk beklage seg over at Visual C++ bruker
> > samme unntakshåndtering for feil på maskinnivå og på språknivå,
> > siden det medfører at "catch(...)" også fanger opp fataliteter som
> > segmenteringsfeil, der utvikleren ofte hadde ønsket seg en
> > øyeblikket avslutning med minnedump i stedet. Man kan kanskje
> > kommer rundt dette problemet ved å sørge for at alle unntak
> > forårsaket av språket gjennom "throw" arver fra en felles
> > superklasse (f.eks. std::exception), slik at man kan bytte ut alle
> > "catch(...)" med "catch(std::exception e)"?
>
> Det "man" ønsker seg, og som "man" forhåpentlig kommer til å oppdage
> innen kanskje 20 år (med mindre utviklingen blir slik man iblant får
> inntrykk av og faktisk begynner å gå bakover) er et
> programmeringssystem som evner å ikke blande sammen handler-bind og
> handler-case. Eller er så generelt hjernedødt at man kan komme på
> tanken å _ønske_ seg en minnedump og prosessdød.
Jeg går gladelig med på at feilhåndteringssystemet til Common Lisp går
C++ en høy gang, og at Common Lisp generelt er et bedre språk enn C++.
Her drodlet jeg litt rundt det feilhåndteringssystemet C++ faktisk har
per i dag. Jeg står ved påstanden om at når ting går veldig, veldig
galt i et program, er det ofte bedre om programmet stanser der og da
og gir deg noe du kan inspisere enn at det prøver å vakle videre og
mister all kontekst som kunne hjulpet deg med å finne feilen. Om
programmiljøet tillater deg å rette feilen og fortsette programmet, i
stedet for at prosessen dør når dette skjer, er selvfølgelig det et
kjempepluss, men jeg kjenner ikke til noen C++-miljøer som tillater
dette. Om man ikke kjører produksjonssystemer gjennom debuggeren, da.
(screen + gdb?)
Er det forøvrig noen av de nye, populære språkene som har like
kraftige feilhåndteringssystemer som Common Lisp? Eller er
utviklingen på vei bakover, slik du frykter over?
Markus B. Krüger
> I no.fag.spraak.fagord skrev Markus B. Krüger <mar...@pvv.org>:
>
> > Er det, eller var det, vanlig å implementere unntakshåndtering i
> > programmeringsspråk med avbrudd?
>
> Hele MS-DOS var implementert som avbrudd. [...]
Her spurte jeg ikke om implementasjonen av OSet, men hvordan man
implementerte håndtering av unntak i programmeringsspråket (exceptions
i C++ og Java, sikkert mange andre navn i andre språk).
Espen Vestre
utviklingen er slett ikke på vei bakover, Common Lisp har nemlig aldri
før vært så anvendelig som idag :-)
--
(espen)
Frode Vatvedt Fjeld
> [..] Jeg står ved påstanden om at når ting går veldig, veldig galt i
> et program, er det ofte bedre om programmet stanser der og da og gir
> deg noe du kan inspisere enn at det prøver å vakle videre og mister
> all kontekst som kunne hjulpet deg med å finne feilen.
Ja selvfølgelig. Det er nettopp dette som er forskjellen på
handler-bind og handler-case som jeg nevnte: Handler-bind holder seg i
konteksten til (feil-)situasjonen, mens handler-case umiddelbart
hopper ut til handler-konteksten. Så C++ (og Java) har bare
tilsvarende handler-case, og dermed et stort problem.
> Er det forøvrig noen av de nye, populære språkene som har like
> kraftige feilhåndteringssystemer som Common Lisp? Eller er
> utviklingen på vei bakover, slik du frykter over?
Man kan jo lure.. Jeg mener, man kan mene hva man vil om C++ og Java
sin syntaks og semikolon og parenteser eller hva det skal være, men at
disse språkene ikke tok denne lærdommen (handler-bind
vs. handler-case) av Common Lisp (og dens forgjengeres)
condition-system syns jeg er forunderlig. (Dvs. jeg har en vag
mistanke om at det kan ha en teknisk årsak (også), nemlig at disse
språkene ikke har closures.) Av det jeg klarer å google meg fram til
på 2 minutter, er C# helt lik Java på dette området (også).
--
Frode Vatvedt Fjeld
Jostein Berrefjord
> Men din argumentasjon henger ikke sammen. Å forstå et ord eller et
> uttrykk betyr at du må få det definert og forklart, ikke at du skal
> forstå det ved bare å lese det. Særlig tekniske uttrykk krever at du
> faktisk setter deg inn i temaet. Det høres ut på deg at man skal
> forstå "kaste et unntak" ved bare å se på ordene. Slik er det
> iallfall ikke i mitt fagfelt fra før, og det kommer det heller ikke
> til å bli.
Ganske mange av innleggene i denne tråden har som implisitt (tildels
eksplisitt) utgangspunkt at dette skal/må/bør være, eller er,
datafolkenes "private" ord, som ikke vedkommer noen som helst andre.
Hvis man arbeider i et rent datamiljø, kan det hende at man slipper
å belemres med ukyndige, slipper å forklare noe som helst.
Problemet er at det faktisk finens masse IKKE-datafolk som kan komme
til å dele med null, om det nå er de selv som har skrevet programmet
eller om de bare bruker det. Hvis du skal forklare noe som helst om
hva som har skjedd, vil du da bruke en helt annen terminologi enn
når du forklarer det samme til en datakollega? Vil du si til legmannen
at programmet har forårsaket en feil, mens du til kollegaen sier at
programmet reiste en eksepsjon? Sier du til mannen med feilmeldingen
på skjermen at den er skrevet ut av den funksjonen som handterer
dette unntaket, mens kollegaen din betegner det som funksjonen
som ketsjer, eller fanger, eller hva du nå velger, unntaket?
Det er ofte bruker-operasjoner som direkte eller indirekte forårsaker
- unnskyld: reiser - unntakssituasjoner, og du blir ofte nødt til
å gi en akseptabel forklaring for å få dem til å forstå hvordan
det skal unngås i framtida. Det er ikke meningen at de skal skjønne
alle detaljene, like lite som jeg skjønner hva bilmekanikeren gjør
når han fikser bilmotoren min. Jeg vet sånn overfladisk hva en
sylinder og et stempel er, jeg skjønner *såvidt* hva en glødeplugg
har med å gjøre. Jeg kan ikke fikse bilen selv, men når mekanikeren
forteller noe om hva han har gjort med den, kan jeg følge med.
Tilsvarende med dataprat til vanlige folk. Jeg vil kunne bruke mitt
fagspråk *uten* at de blir totalt tomme og fjerne i blikket.
Hvis jeg sier at det-og-det "forårsaket en unntakssituasjon", så
skjønner de det; sier jeg at det "reiste et unntak", blir de tomme
i blikket. Sier jeg at "feilsituasjonen er flagget", vet den jamne mann
at situasjonen er identifisert, men enda ikke handtert; sier jeg at
"feilsituasjonen er kastet" blir jeg enten misforstått eller det
samme tomme blikket kommer opp. Sier jeg at "unntaket er handtert"
ser jeg at brukeren lyser opp, fornøyd; sier jeg "unntaket er fanget"
blir han lett irritert og kan gjerne spørre om når vi skal gjøre
noe med det, og hva vi skal gjøre.
Brukeren skjønner på ingen måte detaljene på det tekniske nivået,
men han skiller likevel mellom å forårsake en unntakssituasjon,
oppdage og flagge den, rapportere den, handtere den. Når det faktisk
er slike ting vi *gjør* (forårsaking, identifisering, rapportering,
og handtering), hvorfor skal vi kalle det for noe annet, da?
*Selv om* det bare er vi som vet ale detaljene om hvordan det
hele foregår på teknisk nivå!
> "Throw/catch an exception" er ikke
> "stammespråk" det er teknisk fagspråk, og det er programmerere som
> bruker det. Eller mener du at man skal begynne å skrive fagbøker i
> programmering beregnet på personer som ikke driver programmering?
Unntakssituasjoner finnes i alle fag. Og utenom "fag" også.
Stammespråk er når man finner en eller annen ubetydelig liten nyanse
og bruker den som begrunnelse for å nekte å kalle en spade for en
spade, men insisterer på at "hos oss bruker vi det eksakte begrepet
'feltmessig jorflytningsanodning'". Reelt er det *fordi* ingen andre
skjønner det; det skiller mellom de som er "oss" og de som står
utenfor, men vi har andre "offisielle" begrunnelser. Mange fag
har sine egne presiseringer av den faglige tolkingen av dagligdagse
ord og uttrykk - fra datafeltet kan du f.eks. ta "versjon", som
datafolk som regel tolker eksplisitt til etterfølgende/kronoligisk
utgave. For vanlige folk kan versjoner være engelsk/norsk, stor/
liten skrift, crippleware/fullversjon osv. I mange fag har man
også helt motstridende tolking: Nordmenn flest vil vel si at det
regner generelt mye i Bergen. Spør en matematiker om han i sitt
fagspråk vil hevde at det generelt regner i Bergen (lite eller mye)!
"Generelt" betyr for en matematiker "uten unntak", men for en
vanlig mann "det finnes unntak, selv om dette er det vanlige".
Nei, fagbøker skrives for fagfolk. Men også fagfolk kan snakke om
å forårsake, identifisere, rapportere og handtere unntak.
Også datafolk skal snakke med sine kunder, forklare hvordan
systemene brukes og hvordan de virker. En del av faget er å
beherske dette. Og det er ganske meningsløst om vi skal gå rundt
med en fagbok som lærer fagfolk til at "når du snakker med andre
fagfolk, kaller vi det å fange, men når du snakker med de som
skal bruke systemet, kaller vi det å handtere".
Jostein Berrefjord
> Dette minner meg om hendelsen for en 20 års tid siden da forfatterne
> av IN-110-læreboka (tror jeg det var) ble beæret med medlemskap i
> dusteforbundet pga. definisjonen "En skog er en mengde trær" ;-)
Jeg husker da det skjedde - og irriterte meg. Det var faktisk den som
fikk meg til å "oppdage" at en god del av det F.Stabel plukket opp
faktisk bare var morsomt fordi det var tatt totalt ut av kontekst.
(Men det er jo et artig, og fullt "legalt" virkemiddel i humoren!)
Duverden så mange "selvsagte", ned til det totalt idiotiske, definisjoner
jeg har skrevet ned i forbindelse med ulike utredninger og rapporter!
Erfaring viser at det er absolutt nødvendig. Særlig i kommunikasjon med
folk utenfor ditt eget fagfelt kan du ikke på noen måte stole på at de
bruker ord på samme måte som deg. Ta http://www.nrk.no/musikk/3718720.html -
en konservator som vil "digitalisere" musikken på CD-plater (og med det
mener å overføre dem til magnetisk medium med tanke på langtidslagring).
Eller de mange PC-eiere som betegner kabinettet "CPU".
Jeg krangler til stadighet med folk som insisterer på at "du kan kalle
det hva du vil, men *jeg* kaller boksen 'CPU'". Eller at "I vårt fagmiljø
kan vi ikke godta at datafolk skiller mellom 'kronologiske versjoner' og
'parallelle varianter' - skal du forklare det for oss må du kalle begge
deler for 'utgaver'" (ja, den der er et *stort* problem).
Hadde Stabel fortsatt vært aktiv, og hadde han oppdaget en del av det jeg
har skrevet, ville jeg nok blitt medlem i forbundet, jeg også. Og jeg
ville forsvart fullt ut det jeg har skrevet...
Geir Harris Hedemark
> Tilsvarende med dataprat til vanlige folk. Jeg vil kunne bruke mitt
> fagspråk *uten* at de blir totalt tomme og fjerne i blikket.
Hvorfor i alle dager trenger "vanlige folk" å vite at du bruker
unntak, lange spensthopp, feilmeldinger innkapslet i returobjekter
eller tomatsaus for å implementere feilhåndtering? Min erfaring er at
de er totalt uinteresserte i hvordan ting gjøres så lenge det gjøres
riktig.
Geir
Leif Roar Moldskred
> Stammespråk er når man finner en eller annen ubetydelig liten nyanse
> og bruker den som begrunnelse for å nekte å kalle en spade for en
> spade, men insisterer på at "hos oss bruker vi det eksakte begrepet
> 'feltmessig jorflytningsanodning'". Reelt er det *fordi* ingen andre
> skjønner det; det skiller mellom de som er "oss" og de som står
> utenfor, men vi har andre "offisielle" begrunnelser.
På den andre side sett so _er_ der forskjell på ei spade og ei skuffe,
og fagfelt _treng_ ofte ein meir eksakt terminologi enn det som som
blir nytta i vanleg tale. Det er ikkje for å vere eksluderande at
fysikera skil mellom "varme" og "tempratur", men fordi dei treng å
skille klart mellom dei begrape dei nyttar desse orda på.
--
Leif Roar Moldskred
Espen Vestre
> Eller de mange PC-eiere som betegner kabinettet "CPU".
De er jo relativt opplyste. Den gemene hop kaller det for "harddisken",
de litt mer oppegående "data'n".
--
(espen)
Jon Haugsand
> Tilsvarende med dataprat til vanlige folk. Jeg vil kunne bruke mitt
> fagspråk *uten* at de blir totalt tomme og fjerne i blikket.
> Hvis jeg sier at det-og-det "forårsaket en unntakssituasjon", så
> skjønner de det; sier jeg at det "reiste et unntak", blir de tomme
> i blikket. Sier jeg at "feilsituasjonen er flagget", vet den jamne mann
> at situasjonen er identifisert, men enda ikke handtert; sier jeg at
> "feilsituasjonen er kastet" blir jeg enten misforstått eller det
> samme tomme blikket kommer opp. Sier jeg at "unntaket er handtert"
> ser jeg at brukeren lyser opp, fornøyd; sier jeg "unntaket er fanget"
> blir han lett irritert og kan gjerne spørre om når vi skal gjøre
> noe med det, og hva vi skal gjøre.
Du bruker latterliggjøring og annen retorikk for å antyde at jeg har
meninger jeg ikke har. Jeg har aldri forsvart den norske varianten
"kaste et unntak", og jeg har ikke engang nevnt "reise et unntak", så
om du ønsker å svare på mine innlegg, ber jeg om at du i det minste
prøver å være en smule edruelig.
Jeg kan forøvrig garantere at den jevne mann ikke skjønner mye av
"feilsituasjonen er flagget", og slikt sier jeg ikke til den jevne
mann. Jeg sier at det oppsto en feil -- punktum.
> Mange fag
> har sine egne presiseringer av den faglige tolkingen av dagligdagse
> ord og uttrykk - fra datafeltet kan du f.eks. ta "versjon", som
> datafolk som regel tolker eksplisitt til etterfølgende/kronoligisk
> utgave. For vanlige folk kan versjoner være engelsk/norsk, stor/
> liten skrift, crippleware/fullversjon osv.
Det stemmer ikke. Versjon har akkurat samme betydningsvariasjon for
datafolk som for andre. Vi snakker om norsk versjon av Open Office,
for eksempel. Ordet "versjon" er kontekstavhengig.
>I mange fag har man
> også helt motstridende tolking: Nordmenn flest vil vel si at det
> regner generelt mye i Bergen. Spør en matematiker om han i sitt
> fagspråk vil hevde at det generelt regner i Bergen (lite eller mye)!
> "Generelt" betyr for en matematiker "uten unntak", men for en
> vanlig mann "det finnes unntak, selv om dette er det vanlige".
Dette er første gang jeg hører at "generelt" betyr "uten unntak" for
noen som helst. En matematiker kan snakke om "å generalisere" og da
søker han å utvide en definisjon eller et teorem til en større
mengde. F.eks setningen "alle tall som slutter på 0 er partall" kan
generaliseres til "alle tall som slutter på 0, 2, 4, 6 eller 8" er
partall. Han kan stille spørsmålet "Er setning X generell?" og søker
da å vite om setning X har større gyldighetsområde. Et svar vil da
kunne inkludere betingelser for et evt økt område.
Men dette er OT. Jeg er enig i at ord og uttrykk kan bety ulike ting
for ulike grupper, særlig fagpersoner vs lekfolk. Jeg er også enig i
at dette er uheldig, og at det bør strebes etter samstemte
definisjoner. Et eksempel er at mange mener med "influensa" en
kraftig luftveisinfeksjon, mens leger og ikke minst Folkehelsa har en
bestemt virusstamme i tankene. Spørsmålet er hvem som skal får
"rett", menigmann eller fagfolk. Jeg er av den klare oppfatning at
fagekspertisen skal ha et monopol på definisjoner, og andre har en
moralsk plikt til å følge dem. Presisjon er ekstremt viktig.
Et annet problem, som er nærmere det vi diskuterer, er bruk av
forskjellige ord i fagsjargong og i vanlig tale. Leger synder mest
her, for det heter ikke kreft og brystkasse; det heter cancer og
thorax.
Og for all verden, "kaste et unntak" er en dårlig oversettelse, men
det er også "flagge et unntak" og "reise et unntak".
Liker bedre
gå i unntaksmodus
gå i unntakstilstand
gå i feilmodus
--
Jon Haugsand
Dept. of Informatics, Univ. of Oslo, Norway, mailto:jon...@ifi.uio.no
http://www.ifi.uio.no/~jonhaug/, Phone: +47 22 85 24 92
Jostein Berrefjord
> Er det, eller var det, vanlig å implementere unntakshåndtering i
> programmeringsspråk med avbrudd? Jeg innbilte meg at man som regel
> brukte andre mekanismer, men jeg har ikke lest nok kompilatorkildekode
> eller disassembly til å vite om denne magefølelsen stemmer -- kan noen
> utdype?
Som hovedregel er avbruddshåndtering, på de aller fleste moderne arkitekturer,
en *meget* kostbar mekanisme mhp. eksekveringstid. Hovedgrunnen til å bruke
avbrudd er at det som regel setter CPUen i priviligert modus, slik at
avbruddsrutina kan få tilgang til f.eks. diverse registre der den kan lese
fysiske adresser, prosessorstatus og slikt noe. Pipelinen tømmes, i noen
arkitekturer tømmes sogar cachen helt eller delvis.
Siden en avbruddsrutine har utvidede rettigheter på fysisk nivå, kan den
lett gjøre h.h. for alle andre aktiviteter på maskinen. I OS orientert mot
flerbrukere er det svært sjelden at en ikke-priviligert bruker overhodet har
tillatelse til å legge inn avbruddsrutiner.
Så svaret er, med ekstremt få unntak, at selve unntakshåndteringen *ikke*
gjøres, heller ikke *kan* gjøres, som en avbruddsrutine.
Nå kan avbruddsrutiner være innblandet likevel: Unntaket kan bli detektert
av hardware og *analysert* av en avbruddsrutine. Noen OS lar upriviligerte
program få registrere unntaksrutiner ved kall til OSet. Når det f.eks.
gjøres en divisjon med null aktiviseres avbruddsrutina, som kikker på
OS'ets tabell over registrerte unntaksrutiner. "Javel, det ser ut som om
prosess xxx, som var aktiv nå, vil handtere dette selv. Da gjør jeg ikke
standardhandteringen, som er å terminere prosessen; istedet setter jeg
prosessens programteller til den spesifiserte rutina og avslutter".
Avbruddsrutina kjører priviligert. Når den returnerer, fortsetter
brukerprosessen med modifisert programteller for å kjøre unntaksrutina,
men da i ikke-priviligert modus.
Som sagt: Dette er kostbart. Så det brukes ikke for programvare-genererte
avbrudd. Det finnes maskiner som på hardware-nivå handterer noen avbrudds-
typer "lettere", uten total kontekstskifte, men det er vel ikke lett nok
til å brukes som generell mekanisme.
Det har vært maskiner som har tilbudt programmert avbrudd, gjerne for å
forårsake avbrudd i en annen prosess. Jeg *tror* dette fantes på Norsk
Datas ND-500. ND-500 var en maskin med en kjempeflott arkitektur, ikke
minst i avbruddssystemet, men det viste seg at implementasjonen av det
gikk som lus på to tjærekoster. Så massevis av de arkitekturmessig flotte
mekanismene ble aldri tatt i bruk i praksis, fordi de var for treige.
Gamle, enkle maskiner hadde faktisk ganske rask avbruddshandtering. Gode
gamle NORD-10, fra midten av 70-tallet, utførte første instruksjon i
avbruddsrutina 900 nanosekunder (!! - husk: dette var på 70-tallet!) etter
at avbruddssignalet kom. Neste generasjon, ND-100, var blitt så kompleks
at det tok seks ganger så lang til (5.3 us) før avbruddsrutina var i gang.
(Fortsetter vi videre herfra, bør vel "spraak.fagord" fjernes fra gruppelista!)
Erik Naggum
| Problemet er at det faktisk finens masse IKKE-datafolk som kan komme
| til å dele med null, om det nå er de selv som har skrevet programmet
| eller om de bare bruker det. Hvis du skal forklare noe som helst om
| hva som har skjedd, vil du da bruke en helt annen terminologi enn
| når du forklarer det samme til en datakollega? Vil du si til legmannen
| at programmet har forårsaket en feil, mens du til kollegaen sier at
| programmet reiste en eksepsjon? Sier du til mannen med feilmeldingen
| på skjermen at den er skrevet ut av den funksjonen som handterer
| dette unntaket, mens kollegaen din betegner det som funksjonen
| som ketsjer, eller fanger, eller hva du nå velger, unntaket?
Det høres ut som om du famler etter «feilhåndtering», men fagfolk har
alltid behov for større oppløsning i sin terminologi enn legfolk, og
her snakker vi om forskjellige måter å implementere feilhåndtering.
Exception handling (jeg er motstander av oversettelser) handler (!) om
å la være å bestemme seg for hvordan man skal håndtere en situasjon.
Hvis man vet hvordan man skal håndtere situasjonen, er det idiotisk å
bruke exceptions, fordi disse er runtime-begreper og dersom man kan
unngå runtime-avgjørelser, gjør man det. Hele fenomenet vokste frem
fordi man ikke var fornøyd med å få tilbake en bestemt verdi for å si
fra at noe hadde gått galt og som man alltid måtte teste på og ta seg
av lokalt, men ville ha både sentralisert og dynamisk kontroll med
feilhåndteringen. Men dette er brukeren overhodet ikke interessert i
å måtte belemres med å vite noe om.
Det brukeren er interessert i, er om programmet klarte å gjøre jobben
slik det ble bedt om, og hvis det ikke klarte det, har det klart å la
være å rote til noe som brukeren må rydde opp i? Å designe systemer
som viser graceful degradation ved situasjoner det ikke var forberedt
på å takle, er langt mer komplisert og inngående enn hvorvidt man har
den ene eller den andre feilhåndteringsmekanismen i sproget sitt. Det
handler istedet om å sørge for å implementere transaksjonssemantikk i
systemets bruker-synlige oppførsel, komplett med commit og rollback.
Har man ikke sørget for å la være å gjøre skade om man ikke klarer å
gjøre det man ble bedt om, driter brukeren i /hvordan/ du har fomlet
det til for ham og er utelukkende opptatt av at du /har/ fomlet det
til for ham, slik at han må rydde opp etter deg, for det krever en
ualminnelig stor innsikt i hva det var du ikke lyktes med å gjøre.
Alle som driver og kjaser og maser om oversettelser glemmer bestandig
at de engelske uttrykkene faktisk er i bruk av vanlige folk før de får
en spesiell, innsnevret betydning for fagfolkene. Her hjemme sitter
det folk som ikke kan engelsk nok til å lese en roman eller et dikt og
innbiller seg at et uttrykk liksom er et så spesielt «data-uttrykk» at
brukeren må beskyttes fra det. Jeg har møtt folk som mener at «file»
er noe annet enn den mappen man legger saksdokumenter i, og som ikke
klarer å innfinne seg med at en «saksmappe» kalles «file» på engelsk,
for de har liksom «brukt opp» den betydningen til en snever fagterm,
men engelsk er ikke et ett-ord-én-mening-sprog. Det som gjør engelsk
til et så fremragende sprog er at man uten problemer kan bruke et ord
til noe annet enn det nordmenn tror er den eneste betydningen.
Det er ikke norske brukere som har et problem med faguttrykk, det er
de nissene som tror at de kan engelsk fordi de kan noen få faguttrykk,
og som derfor ikke evner å forestille seg hvordan en som kan engelsk
leser og forstår det alminnelige uttrykket i en faglig sammenheng.
Databransjens «faguttrykk» er ikke i nærheten av andre fags /ekte/
faguttrykk. Når engelsktalende vanlige brukere snakker om «file»,
«folder», «directory», og «disk», forstår de intuitivt hva det er og
hva de kan forvente seg av det som bærer det navnet, men det samme
gjelder bare ikke de norske «oversettelsene» som tar utgangspunkt i
den amerikanske kontorhverdagen som er vesensforskjellig fra den
norske, og som derfor resulterer i fullstendig malplasserte termer.
Det er ille nok at TV3 tror at folk er tjent med at niksepinner uten
stedlig engelskkompetanse skal oversette filmer og serier så dårlig at
det er vanskelig å se på dem selv når man spoler forbi reklamen, men
når folk med et engelsk-vokabular på kanskje 10,000 ord skal sette seg
ned for å bli enige om hvordan man oversetter misforståtte faguttrykk
til norske misforståelser, da blir det hele bare komisk, om det ikke
var for at folk tar det så skrekkelig alvorlig.
Mitt forslag er at folk istedet lærer seg engelsk (meget) bedre og da
legger vekt på amerikansk engelsk. Britisk er bare harry, og dessuten
marginaliserer de seg så mye for tiden at det er bortkastet å forsøke
å holde styr på alle de talentløse feilene de tror er signaler til
omverdenen om deres unike identitet. Dessuten kan man snakke fransk
om man synes det er kult å utelate halvparten av stavelsene og lydene,
ikke den billige etterligningen. Konkret er mitt råd til folk som
tror de forstår engelsk fordi de kan noen «faguttrykk» å lese /mye/
amerikansk litteratur, hvor man starter med skjønnlitteratur og holder
på med dét til man ikke har problemer med å forstå hele meningsdybden
i gode forfatteres rike sprogbruk. Dette er nemlig hva de som skriver
«faguttrykk» på engelsk gjør, slik at det de skriver ikke fortoner seg
/for dem/ som faguttrykk i det hele tatt. Slik bør det også være på
norsk, men det er altfor få som skriver på et så godt nok norsk at det
er noe nevneverdig litteratur å få med seg før man begynner å skrive
fagstoff på norsk, og da er det ikke nynorsk som er problemet, men at
nordmenn har et forstemmende dårlig forhold til seriøs sprogrøkt, noe
forøvrig de latterlig talentløse oversettelsene av data-utrykk viser
med overdreven tyngde.
Ellers er det et generelt og meget godt råd til alle de som har lyst
til å uttrykke sine tanker og idéer og løsninger i programmeringssprog
at de kan uttrykke seg presist og konsist skriftlig på sitt morsmål.
Kan man ikke dét, er det på tide å studere norsk, ikke programmering.
--
Erik Naggum, Oslo, Norway | HTML mail is discarded unread | 2004-118
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Alf P. Steinbach
> al...@start.no (Alf P. Steinbach) writes:
>
> > * Markus B. Krüger:
> > > * Alf P. Steinbach:
> > > > * Markus B. Krüger:
> > >
> > > Med andre ord ser det for meg ut som om hvorvidt noe er et unntak
> > > eller et avbrudd ikke har noen betydning for den som skriver en
> > > rutine på maskinkodenivå for å håndtere unntaket eller avbruddet.
> > > Dette kan kanskje forklare hvorfor jeg ikke kan huske noe slikt
> > > skille.
> >
> > Siden jeg er pedantisk anlagt i njus-diskusjoner vil jeg gjerne påpeke
> > at innvendingen din mot min første posting tilsynelatende var motsatt,
> >
> > > > > Den gang jeg holdt på med MS-DOS-programmering, kan jeg ikke
> > > > > huske at avbrudd noensinne ble likestilt med eller referert
> > > > > til som unntak.
> >
> > Så, er det det ene eller det andre? ;-)
>
> Jeg kunne ikke huske at begrepet "unntak" ble brukt om noe som helst
> på assembly-nivå. Jeg ser nå at Intel brukte dette begrepet, derav
> forklaringen min over: jeg tror grunnen til at jeg ikke husker eller
> aldri fikk med meg unntak (igjen, på assembly-nivå), eller skillet
> mellom unntak og avbrudd, fra MS-DOS-dagene, fordi det fra
> programmererens synspunkt ikke *var* noe skille mellom dem, og at det
> dermed ikke var noen grunn til å bruke to begreper der det holdt med
> ett.
Det går ikke helt klart fram hva du mener, men som jeg forklarte
tidligere er det på x86 intet skille på maskinkodenivået.
På den andre siden er det god grunn til å skille mellom begrepene, og
derfor gjør Intel (og jeg, og andre) det.
For eksempel kan en avbruddsrutine ha en tidsbegrensning, mens en
unntaksrutine sjelden har en tidsbegrensning. Så helt uavhengig av
ekstra avbruddsrutine kode for å støtte hardware'n er det forskjell på
hva man bør finne på å gjøre i henholdsvis avbrudd og unntak.
Terminologi: i synspunktet avbruddsmekanisme også brukt for unntak kan
et maskinkode unntak benevnes som et "software interrupt"; i synspunktet
unntaksmekaisme også brukt for avbrudd kan et avbrudd betegnes som en
"hardware exception".
> > > Ok, så en "throw" kompilert av Visual C++ ender før eller siden
> > > opp i maskinkoden "int"? Eller misforstår jeg?
> >
> > Tror ikke du misforstår men det der vet jeg ikke og gidder ikke å
> > sjekke.
>
> Vel, det var egentlig det jeg bet meg merke i. Du skrev i
> <408e95e9....@news.individual.net>:
>
> Disse to anvendelsene viser etter min oppfatning at
> unntakshåndtering på maskinkodenivået er noe helt annet og brukes
> til helt andre ting enn unntakshåndtering i høyere nivå språk (selv
> om maskinkodenivå unntak også brukes i bunnen av høyere nivå språks
> unntaksmekanismer).
>
> Kommentaren i paranteser mener jeg er feil: avbrudds- og
> unntaksrutinene for x86-prosessoren som installeres av Windows
> resulterer i kall til samme mekanismer som unntak i C++, men det betyr
> ikke at C++ bruker maskinkodenivå unntak
Som jeg forklarte tidligere: en C++ implementasjon kan bruke
maskinkodenivå unntak til å fange opp for eksempel nullpeker
dereferanse, divisjon på null, flyttallsfeil, etc. Og jeg har gitt som
eksempel en implementasjon som gjør det, nemlig Visual C++. Å slik
bruke maskinkodenivå unntak i bunnen av unntakshåndteringen er typisk
den _eneste_ praktiske måten å fange opp disse feilene på.
> med mindre du med
> maskinkodenivå unntak mener SEH og ikke unntak slik Intel definerer
> dem.
Som jeg forklarte tidligere er SEH et nivå over maskinkode unntak.
> Frode Vatvedt Fjeld skriver forøvrig i
> <2hd65th...@vserver.cs.uit.no> at maskinkoden "int" *ikke* brukes
> i implementasjonen av C++-konstruksjonen "throw".
1. Frode er helt på linje med meg (nødvendigvis, siden fakta er fakta).
2. Med velvillig tolking er det du siterer Frode på også det jeg skrev.
3. Men jeg tviler på at Frode skrev det akkurat slik som du siterer her,
det var i så fall trolig en liten formuleringsfeil.
Som jeg forklarte tidligere, og det jeg husker at Frode så også
forklarte, og som jeg nå har forklart enda en gang ovenfor, er det
typiske at et maskinkode unntak fører til et C++ unntak (i en
implementasjon som støtter for eksempel nullpeker-feil som unntak), mens
det motsatte så vidt jeg vet ikke er brukt.
Alf P. Steinbach
>
> > mar...@pvv.org (Markus B. Krüger) writes:
> >
> > > Ok, så en "throw" kompilert av Visual C++ ender før eller siden opp
> > > i maskinkoden "int"? Eller misforstår jeg?
> >
> > Du misforstår.
>
> Nei, jeg misforsto ikke Alf, men Alfs påstand var feil. :-)
Din forvirring er ikke min feil, nei.
Ei heller noen feil påstand.
Skjerpings.
Markus B. Krüger
> * mar...@pvv.org (Markus B. Krüger) schriebt:
>
> > Du skrev i <408e95e9....@news.individual.net>:
> >
> > Disse to anvendelsene viser etter min oppfatning at
> > unntakshåndtering på maskinkodenivået er noe helt annet og
> > brukes til helt andre ting enn unntakshåndtering i høyere nivå
> > språk (selv om maskinkodenivå unntak også brukes i bunnen av
> > høyere nivå språks unntaksmekanismer).
> >
> > Kommentaren i paranteser mener jeg er feil: avbrudds- og
> > unntaksrutinene for x86-prosessoren som installeres av Windows
> > resulterer i kall til samme mekanismer som unntak i C++, men det
> > betyr ikke at C++ bruker maskinkodenivå unntak
>
> Som jeg forklarte tidligere: en C++ implementasjon kan bruke
> maskinkodenivå unntak til å fange opp for eksempel nullpeker
> dereferanse, divisjon på null, flyttallsfeil, etc.
Ja, dette er jeg helt med på. Men når du skrev at "maskinkodenivå
unntak også brukes i bunnen av høyere nivå språks unntaksmekanismer",
tolket jeg dette som at du mente at høynivåspråks unntaksmekanismer
var *implementert* med unntak på maskinkodenivå. Jeg oppfatter det nå
som at det du mente var at høynivåspråk kan bruke unntak på
maskinkodenivå til å fange opp noen feil man ellers ikke kunne fanget
opp, men at selve implementasjonen av unntaksmekanismen i språket
ellers ikke har noe med mekanismene for maskinkodenivåunntak.
For å være mer konkret: det første innlegget ditt ga meg inntrykket
av at du mente at en normal "throw" i C++ medførte et kall til en
avbruddsrutine i IDTen, og det var dette jeg reagerte på. Jeg innser
nå at det ikke var det du mente, og beklager denne misforståelsen.
Samtidig har det vært en lærerik debatt, så jeg kan ikke si jeg angrer
glippen fullstendig. :-)
Markus B. Krüger
> * mar...@pvv.org (Markus B. Krüger) schriebt:
> > Frode Vatvedt Fjeld <fro...@cs.uit.no> writes:
> >
> > > mar...@pvv.org (Markus B. Krüger) writes:
> > >
> > > > Ok, så en "throw" kompilert av Visual C++ ender før eller siden opp
> > > > i maskinkoden "int"? Eller misforstår jeg?
> > >
> > > Du misforstår.
> >
> > Nei, jeg misforsto ikke Alf, men Alfs påstand var feil. :-)
>
> Din forvirring er ikke min feil, nei.
>
> Ei heller noen feil påstand.
Vel, du skrev i <408ed3cf....@news.individual.net>:
Tror ikke du misforstår men det der vet jeg ikke og gidder ikke å
sjekke.
Dermed trodde jeg at jeg hadde mitt på det tørre med at jeg ikke hadde
misforstått deg, siden du vitterlig skrev det selv. Men det var
flåsete skrevet av meg, og det beklager jeg. Poenget mitt var at det
ikke var min oppfatning at "throw" brukte "int" -- noe av hele grunnen
til jeg begynte å skrive var at det hørtes rart ut for meg, og jeg
ville påpeke for Frode og andre at dette ikke var min påstand, men min
forståelse (eller misforståelse, som det senere viste seg) av din
påstand.
Thore Karlsen
<address...@example.net> wrote:
>> Et alternativ til kaste/heve/heise kan
>> være "erklære", som i "erklære et unntak".
>Glimrende! Akkurat det begrepet jeg famlet etter, med akkurat de rette
>assosiasjonene. Signaliserer at det er noe man _bestemmer_ seg for å
>gjøre, i motsetning til "forårsake" som høres ut som det betyr "cause",
>som igjen ikke er det samme som "throw"/"raise".
>
>Muligens en forvirringsfare at i mange tilfeller er
>"erklære"=="declare" mens "declare"!="raise". Men datafolket sier jo
>som regel "deklarere" og ikke "erklære" om å definere variable osv
>(forøvrig med dekning i radisjonen, jf. "tolldeklarasjon"), så det
>burde gå bra.
Jøje meg. Jeg er glad jeg ikke jobber i Norge lenger, for dette hadde
jeg ikke klart å leve med.
--
Be seeing you.
Jon Haugsand
> Jøje meg. Jeg er glad jeg ikke jobber i Norge lenger, for dette hadde
> jeg ikke klart å leve med.
Litt upassende å komme med slike oppstøt i en seriøs diskusjon. Kan
du begrunne din døden-nær-forståelse av dette?
Thore Karlsen
>> Jøje meg. Jeg er glad jeg ikke jobber i Norge lenger, for dette hadde
>> jeg ikke klart å leve med.
>Litt upassende å komme med slike oppstøt i en seriøs diskusjon. Kan
>du begrunne din døden-nær-forståelse av dette?
Problemet nå er at det ikke er noen gode uttrykk for disse tingene på
norsk, så det er forvirrende å måtte forholde seg til alle de
forskjellige. Jeg må stoppe og tenke meg om for å assosiere norske
uttrykk med uttrykkene jeg allerede kjenner på engelsk, og det er
slitsomt når jeg prøver å konsentrere meg om innholdet, som oftest er
teknisk og krever konsentrasjon. Tankegangen min blir avbrutt, og jeg må
starte på ny. Spesielt når det er noe så unaturlig som "erklære et
unntak".
Man kan venne seg til alt, så lenge det er konsistent. Men jeg har ikke
sett at forsøk på å fornorske programmeringsteknisk terminologi har vært
særlig heldige så langt.
--
Be seeing you.
Jon Haugsand
> Problemet nå er at det ikke er noen gode uttrykk for disse tingene på
> norsk, så det er forvirrende å måtte forholde seg til alle de
> forskjellige. Jeg må stoppe og tenke meg om for å assosiere norske
> uttrykk med uttrykkene jeg allerede kjenner på engelsk, og det er
> slitsomt når jeg prøver å konsentrere meg om innholdet, som oftest er
> teknisk og krever konsentrasjon. Tankegangen min blir avbrutt, og jeg må
> starte på ny. Spesielt når det er noe så unaturlig som "erklære et
> unntak".
>
> Man kan venne seg til alt, så lenge det er konsistent. Men jeg har ikke
> sett at forsøk på å fornorske programmeringsteknisk terminologi har vært
> særlig heldige så langt.
Her er nok de fleste enige med deg. Men det er jo faktisk en
diskusjon for å finne den beste norkse oversettelsen, og inntil da kan
vi alle gjøre som de fleste av oss faktisk gjør: bruke de engelske
termene.
Men om vi finner en god norsk oversettelse, en som det er nær
konsensus om, kan denne begynne å bli almengyldig. Du behøver ikke
forholde deg til mer enn en oversettelse, og dessuten en som faktisk
blir definert i de bøkene den brukes.
Jeg skjønner utmerket godt dem som foretrekker at man ikke oversetter
slike uttrykk. Men jeg har en liten hang til språklig estetikk --
også på norsk.
Vetle Roeim
Rolig nå. Det er ikke slik at alle utviklere i Norge bruker norske
uttrykk for alt mulig rart. Når jeg tenker meg om så kjenner jeg
faktisk ingen som bruker ordet 'unntak' i stedet for 'exception'.
--
#!/usr/bin/vr
Terje Kvernes
[ ... ]
> Rolig nå. Det er ikke slik at alle utviklere i Norge bruker norske
> uttrykk for alt mulig rart. Når jeg tenker meg om så kjenner jeg
> faktisk ingen som bruker ordet 'unntak' i stedet for 'exception'.
'closures' og 'continuations' blir fine ting når man forsøker å
oversette de til norsk. mye av problemet er at i hvert fall jeg
ikke er i "kode-kontekst" når jeg hører begreper på norsk, slik at
jeg må tenke hardt over hva som _egentlig_ sies.
--
Terje
Jon Haugsand
> 'closures' og 'continuations' blir fine ting når man forsøker å
> oversette de til norsk. mye av problemet er at i hvert fall jeg
> ikke er i "kode-kontekst" når jeg hører begreper på norsk, slik at
> jeg må tenke hardt over hva som _egentlig_ sies.
Tja, det har vel litt med vane å gjøre. Er nesten sikker på at vi
kalte "continuation" for "fortsettelse" i faget /Denatosjonell
semantikk/ og en "closure" er jo veldefinert i matematikken og kalles
her "tillukning".
Men jeg skjønner jo at det er uvant, og ofte ikke verdt bryet med å
oversette.
Alf P. Steinbach
>
> 'closures' og 'continuations' blir fine ting når man forsøker å
> oversette de til norsk.
Klosett og kontinens? <dukke/>
Jostein Berrefjord
> Du bruker latterliggjøring og annen retorikk for å antyde at jeg har
> meninger jeg ikke har.
Unnskyld? Er du *littegranne* følsom i dag?
Dette er en åpen debatt med mange deltakere. Jeg skrev et innlegg
til debatten generelt, ikke som et personlig svar til akkurat det
*du* sa, men til det som har kommet fram i debatten.
Ja, jeg tok utgangspunkt i noe jeg siterte fra ditt innlegg. Min
første setning startet med "Ganske mange av innleggene i denne
tråden har som implisitt (tildels eksplisitt) utgangspunkt ..."
Altså, jeg refererte *eksplisitt* til hele tråden som sådannet.
Særlig da - men igrunnen generelt - må det være anledning til å
kommentere andres forslag og argumentet, selv om jeg skulle
komme til å gjøre det med *utgangspunkt* i noe som kommer fra deg.
Det du siterer står flere avsnitt under det du skrev, og er ikke
knyttet direkte til det du har skrevet.
Jeg har *ikke på noen måte* hevdet at du mener verken det ene
eller det andre. Hvis du mener at oppfølgere til dine innlegg
ikke må nevne noe som helst som du ikke går god for, så blir
debatten mildt sagt hemmet av det!
Du reagerte jo tilsvarende tidligere her, når du refererte til "ganske
direkte oversettelse", og jeg sier at jeg "faller ikke helt for
arguementet 'ganske direkte oversettelse'" - det mente du også
at var å tillegge deg meninger. Det er jo høyst kunstig hvis jeg
må finne et *annet* innlegg å følge opp for å kunne fortelle at
jeg ikke synes direkte oversettelse er noe godt argument. Skal jeg
da ikke få si min mening om dette? Eller må jeg innlede slike
uttalelser med "Som vi alle kan se, har ikke JH på noen måte
antydet at direkte oversettelse skulle være et argument den ene
eller den andre veien, men hvis noen *andre* skulle mene noe slikt,
så ville jeg ikke synes det var noe gyldig argument..."
Jada, jada - *i teorien* kan man vri det til at fordi jeg avviser
det som argument, har jeg tillagt deg at du skulle ha ment det som
et argument i saken, mens du egentlig ikke mente noe som helst
med det. Men jeg opplever noe slikt som en ganske følsom reaksjon.
> Jeg har aldri forsvart den norske varianten
> "kaste et unntak", og jeg har ikke engang nevnt "reise et unntak", så
> om du ønsker å svare på mine innlegg, ber jeg om at du i det minste
> prøver å være en smule edruelig.
Var det jeg skrev "ikke edruelig"? Var det "Latterliggjøring"?
Jeg tror du må være den eneste som oppfattet det som et forsøk på
latterliggjøring av deg. Jeg vet faktisk ikke hva du mener er så
latterliggjørende. Det ene er at det du siterte fra mitt innlegg
kommer et antall avsnitt etter referansen til ditt innlegg.
Det *er* faktisk slik at valige folk blir "tomme og fjerne i
blikket" når du snakker kryptisk til dem - det er slett ikke å
latterliggjøre deg å påpeke det. Og de formuleringene jeg satte opp
mot hverandre *har* faktisk blitt foreslått seriøst i debatten.
Nei, jeg tror ikke jeg tar meg bryet med å føre dette videre. Jeg
velger å tolke det som at du har en dårlig dag...
Jeg blir litt nervøs for at enhver videre faglig diskusjon fra min
side også denne gang vil bli tolket som latterliggjøring, lite
edruelig og å tillegge deg meninger du ikke har. Jeg tar likevel
sjansen :-)
> > Mange fag
> > har sine egne presiseringer av den faglige tolkingen av dagligdagse
> > ord og uttrykk - fra datafeltet kan du f.eks. ta "versjon", som
> > datafolk som regel tolker eksplisitt til etterfølgende/kronoligisk
> > utgave.
> Det stemmer ikke. Versjon har akkurat samme betydningsvariasjon for
> datafolk som for andre. Vi snakker om norsk versjon av Open Office,
> for eksempel. Ordet "versjon" er kontekstavhengig.
Jeg sa ikke noe absolutt, jeg sa "som regel". Og som du sier: "Versjon"
er kontekstavhengig - som jeg også skrev. Siden jeg brukte det bare
som et eksempel til en mer generell uttalelse, presiserte jeg ikke
konteksten så veldig nøye; jeg tenkte på en *programutviklings*-
kontekst, ikke ethvert sted der man bruker kontorstøtte-programvare.
*Der* har man ofte den folkelige, upresise betydningen.
Jeg vil påstå at terminologien fra SCCS *har* hatt en betydelig innflytelse
på programutviklingsfolk og deres bruk av ordene. Som sagt: "Som regel",
ikke absolutt. Men jeg vil også påstå at det derfra har smittet over
på en god del beslektede felter innen de rene databehadlingsmiljøene;
jeg har sett flere dataordlister som har definert versjon/variant slik.
Selv om ikke nødvendigvis alle som bruker ordene har referanser til formelle
uavhengige definisjonslister, er SCCS-tolkingen sterkt dominerende i
datafaglig stoff. De aller fleste som driver med programutvikling og møter
disse definisjonene av versjon/variant i prosjektets eller firmaets
offisielle terminologi-liste, vil nikke gjenkennende: Ja, slik er det.
Men det er helt klart at disse definisjonen *ikke* er så sterkte at
de er enerådende i markedsføring av kontorstøttesystemer, nei. Det må vel
et reelt behov for å kunne skille mellom versjoner og varianter til
for at termene skal defineres klart, og det behovet er rett og slett
ikke sterkt nok i forbindelse med Open Office. Det er langt sterkere i
programvareutvikling.
Men uansett dette eksempelet: Det burde ikke være noen tvil om det
generelle poenget, at fagfolk ofte har en mer presis definisjon av termer
enn det ikke-fagfolk har. *Det* har jeg inntrykk av at vi er fullt ut enige om.
> Dette er første gang jeg hører at "generelt" betyr "uten unntak" for
> noen som helst.
Jøss! Da har jeg misforstått din bakgrunn. Vel, jeg har ikke noen
avansert mattebok for hånden her og nå, men det burde ikke være
vanskelig å finne. En generell formel for å beregne dette eller
hint, en gerenell løsning av et ligningssystem, ...
> En matematiker kan snakke om "å generalisere" og da
> søker han å utvide en definisjon eller et teorem til en større mengde.
Nettopp. Og den generelle definisjonen som gjelder for *hele*
mengden, den han får ved å generalisere så langt som det er mulig,
den omfatter *hele* domenet. Det er ingenting som faller utenom.
Den Endelige Generalisering omfatter alt, uten unntak.
> F.eks setningen "alle tall som slutter på 0 er partall" kan
> generaliseres til "alle tall som slutter på 0, 2, 4, 6 eller 8" er
> partall.
Ja, dette er en generell regel. Det finnes ingen unntak.
> Han kan stille spørsmålet "Er setning X generell?" og søker
> da å vite om setning X har større gyldighetsområde. Et svar vil da
> kunne inkludere betingelser for et evt økt område.
Betingelsene er en kvalifisering av den generelle setningen, som derfor
ikke er helt generell. Hvis setning X var helt generell, ville det ikke
stilles noen betingelser, ingen innskrenking av gydlighetsområdet.
Ingen unntak.
En matematiker kan nok gå med på å bruke betegnelsen "generell"
også når generaliteten er redusert av uttalte tilleggsbetingelser.
Men likevel er han ikke i tvil om at en mer generell regel dekker
flere tilfeller, har færre unntak, enn en mindre generell regel.
Og en absolutt generell regel har ingen unntak (innen det aktuelle
domenet/problemområdet, naturligvis).
Spør du en vanlig mann: "Er det alltid kaldere i Nord-Norge enn
sørpå?" kan han svare "Ja, generelt er det jo slik, men ...".
Spør du en matematiker om en formel alltid gjelder, svarer han
neppe: Ja, formelen er generell, men den gjelder ikke da-og-da.
Han ville heller si at formelen *ikke* er helt generell, den
gjelder bare for X > 0, eller noe slikt.
> Spørsmålet er hvem som skal får
> "rett", menigmann eller fagfolk. Jeg er av den klare oppfatning at
> fagekspertisen skal ha et monopol på definisjoner, og andre har en
> moralsk plikt til å følge dem. Presisjon er ekstremt viktig.
Fra et *praktisk* synspunkt har du vel rett. Men i mange sammenhenger
vil det forbli et uoppnåelig ideal, et fjernt mål. Selv om et samlet faglig
miljø, uansett fag, mener at Folket er "moralsk forpliktet" til f.eks. å
kun kalle det som *egentlig* er influensa for "influensa", kun kalle de
metoder som bruker *optiske* teknikker for å gjenkjenne tegn itekst trykt
på papir for "OCR", ikke omtale en CD som kan skrivesbsom "Read Only" (CD-ROM)
osv osv, så vil det ikke skje i praksis. Vi kan prøve å *påvirke* ikke-
fagfolk, men til syvende og sist er det allmuen som utformer allmuens språk.
(Apropos "syv": "Den nye tellemåten" var jo et forsøk på å tre språk ned
over hodet på allmuen; språk-ekspertisen lyktes *delvis*, men etter drøyt
femti år gav de jo opp håpet om fullt gjennomslag, og begynte igjen å tillate
det språket (endel) folk reelt benytter!)
Det andre problemet er at "fagekspertisen" taler med mange tunger.
Når ulike fag møtes til tverrfaglig arbeide, er det heller normen
enn unntaket at man får større eller mindre problemer på grunn av
ulike tolkinger av ord og begreper - særlig innen det grenselandet
mellom fagene som er grunnlaget for tverrfagligheten!
Og selv innen faget: Du kan se de reneste bikkjeslagsmål når ulike
fag-autoriteter gir seg til å krangle f.eks. om konsept X også
omfatter fenomen Y, og lignende. Så fagekspertisens monopol på definisjoner
blir altfor ofte et duopol, et trippelpo, kvadruppelpol... :-)
Det er også en psykologisk side: Hvis du stiller opp som datamann i et
ikke-datafaglig miljø, f.eks. i forbindelse med at det skal innføres
databaserte hjelpemidler, og forkynner at "Vi datafolk har definert at en
TrueType-fil spesifiserer en *font* - dette er et datateknisk veldefinert
begrep. Ordet 'skriftsnitt', som ikke har vært entydig definert, bortfaller
fra nå av!" - da vil du nok bli oppfattet som ganske arrogant! Brukerne vil
neppe føle den store moralske forpliktelsen overfor deg. Du har adskillig
større sjanser for å lykkes hvis den terminologien du foreslår faktisk vekker
gjenklang i de ikke-faglige brukermiljøene, m.a.o. at de definisjoner du
presenterer i all hovedsak er *presisering* av eksisterende uformell
terminologi.
Og da har vi navigert tilbake til unntak og denslags...
Hva er det som vil vekke gjenklang hos folk som du skal forsøke
å lære (f.eks. studenter på høyskole/universitet) hva "exception"
er for noe? Finner du noe som vekker gjenklang hos ferske data-
studenter, vil det trolig være et godt utgangspunkt hvis du en
gang skal forklare saker for folk som ikke har blitt og heller
aldri vil bli datastudenter, dvs. "vanlige folk". Sier du
"skrifsnitt" istedetfor "font", vekker det gjenklang. Sier du
"forårsake en feil" vekker det også gjenklang. "Unntak" er litt
mindre folkelig enn "feil", men når du vil forklare at det faktisk
ikke nødvendigvis er en *feil*, bare et unntak fra hovedregelen
(for hvordan systemet oppfører seg), er ikke avstanden så stor;
den kan ikke-datafolk (og ikke ferdig utdannede datatolk) hanskes med.
Et unntak er noe som må handteres - den er også helt grei for folk uten
den minste databakgrunn.
> Liker bedre
>
> gå i unntaksmodus
Et forslag verd å vurdere. Men legg merke til at det ligger i
det at "noe" (systemet, på ett eller annet nivå), går inn i en
særskilt *modus* - det avgrenser begrepet noe. En modus er noe
som er stabilt over en viss tid; det utelukker situasjoner som
blir handtert (endelig) umiddelbart/fortløpende. Uttrykket omfatter
heller ikke de unntakstilfellene som *ikke* blir behandlet, bare
avvist som verdig til behandling - men det var kanskje intensjonen?
> gå i unntakstilstand
Mer folkelig enn "modus", ja. For folk flest er "modus" gresk (*er*
det det også??) - "tilstand" er noe de vet hva betyr, grovt sett.
Så jeg ville foretrekke det framfor "unntaksmodus".
> gå i feilmodus
Eller "feiltilstand". :-) Her begrenser du det til det som er reelle
*feil*, og det behøver slett ikke være tilfelle. For endel år siden,
dengang NTH enda var NTH og kjørte store Univac mainframes, satte de
opp en tellerutine som telte opp antall divisjoner med null på Univac'en
i løpet av en dag - det var hundretusenvis, og ble presentert med stor
overskrift i info-lefsa deres. Det var først etter den "sensasjonen"
at noen av matematikerne gjorde RUNIT-folkene oppmerksom på at det
i endel matrise-beregninger var helt normalt med en masse divisjon
med null - algoritmene var slik at disse delresultaten ikke ble
ført videre i beregningene, men det var mye enklere og raskere å
handtere alle elementene likt enn å "luke ut" på et tidligere
stadium de delberegningene som ikke var aktuelle.
Når noe er forventet og "normalt" bør det vel ikke omtales som en
"feil". Det er heller ikke en "feil" om en bruker gir en kommando
om at f.eks. en aktivitet skal stoppes, men handteringen av denne
kommandoen kan gjerne være handtert med unntaksmekansimer i prosessen.
"Feil" kan være riktig ord hvis det faktisk *er* en feil, men det
er feil å si feil hvis det *ikke* er en feil :-)
Jon Haugsand
> > Du bruker latterliggjøring og annen retorikk for å antyde at jeg har
> > meninger jeg ikke har.
>
> Unnskyld? Er du *littegranne* følsom i dag?
Du skriver mye interessant som jeg er ganske enig i, men endel jeg har
andre syn på. Det er greit og sunt i en diskusjon.
Men jeg synes det over tenderer til persondiskusjon og det orker jeg
ikke være med på. Jeg melder meg ut inntil videre.
Jostein Berrefjord
> Hvorfor i alle dager trenger "vanlige folk" å vite at du bruker
> unntak, lange spensthopp, feilmeldinger innkapslet i returobjekter
> eller tomatsaus for å implementere feilhåndtering? Min erfaring er at
> de er totalt uinteresserte i hvordan ting gjøres så lenge det gjøres
> riktig.
Det er ganske vanlig at unntak har å gjøre med eksterne forhold som
f.eks. er forårsaket av hva en bruker gjør, hvilke data han gir programmet
eller sånt noe. Eller andre, ytre forhold som ikke brukeren nødvendigvis
har kontroll over, men som han har ett eller annet forhold til.
Det er slett ikke sjelden at brukeren på en eller annen måte blir
oppmerksom på unntakssituasjonen, direkte eller indirekte.
Det spiller ikke noen prinsipiell rolle om det er 90% eller 95% (eller for
den saks skyld 99%) av all unntakshandtering som verken vedkommer brukeren
på den ene eller den andre måten - uansett er det igjen mange nok tilfeller
der det kan være god grunn til å kommunisere med brukere om det som skjer
i systemet i forbindelse med unntakshandtering.
Nei, selvfølgelig behøver ikke brukerne vite om tomatsaus og spensthopp.
Men man må ofte fortelle en bruker *om* at man gjør unntakshandtering, selv
om man ikke går inn på tomatsausen og denslags. Sånn er det med alle ting
der fagfolk gjør noe for ikke-fagfolk - en rørlegger kan fortelle at de
gamle jernrørene har rustet igjen, selv om huseieren ikke aner at rust har
noenting med oksydasjon å gjøre. For noen måneder siden sirkulerte det
på nettet en liste med påståtte feilrapporter og kvitteringer fra service-
personale i et flyselskap: "Noe er løst i cockpiten". Kvittering: "Noe har
blitt festet i cockpiten". (Husker ikke eksakt ordlyd, men det var noe sånt.)
Jeg tror ikke vi vinner så mange stjerner hos brukerne hvis vi tar en slik
holdning til feil og unntak.
Thore Karlsen
wrote:
>> Rolig nå. Det er ikke slik at alle utviklere i Norge bruker norske
>> uttrykk for alt mulig rart. Når jeg tenker meg om så kjenner jeg
>> faktisk ingen som bruker ordet 'unntak' i stedet for 'exception'.
> 'closures' og 'continuations' blir fine ting når man forsøker å
> oversette de til norsk.
Lukninger og fortsettelser? :)
> mye av problemet er at i hvert fall jeg
> ikke er i "kode-kontekst" når jeg hører begreper på norsk, slik at
> jeg må tenke hardt over hva som _egentlig_ sies.
Jepp.
--
Be seeing you.
Geir Harris Hedemark
> Det er ganske vanlig at unntak har å gjøre med eksterne forhold som
> f.eks. er forårsaket av hva en bruker gjør, hvilke data han gir programmet
Da er det det brukeren gjør som bør være fokus, ikke hvordan du
programteknisk gjør noe med feilen.
> Nei, selvfølgelig behøver ikke brukerne vite om tomatsaus og spensthopp.
> Men man må ofte fortelle en bruker *om* at man gjør unntakshandtering, selv
> om man ikke går inn på tomatsausen og denslags. Sånn er det med alle ting
"Håndtering av feilsituasjonen". Det er alt brukeren følger han
trenger å vite.
Jeg ser ingen grunn til å starte en stor diskusjon om akkurat denne
kommunikasjonen. Den beste måten å kommunisere det du vil vil forandre
seg avhengig av personen du snakker med. Jeg ser ikke det å diskutere
fram et standard begrepsapparat som veldig fruktbart i den
sammenhengen.
> personale i et flyselskap: "Noe er løst i cockpiten". Kvittering: "Noe har
Joda, jeg har jobbet relativt lenge som supporthode i en tidligere
tid. Det betyr ikke at jeg gjorde det til et poeng å fortelle brukerne
om innmaten i det de brukte. Det er ikke det brukeren oppfatter som et
problem, og han vil for det meste bare se tomt på deg og lure på når
du skal slutte å fakturere ham for å prate skit. De store
konsulentselskapene gjorde forsåvidt store penger på å produsere
timer, og dersom det er det du synes er gøy så kjør for all del den
linja.
Det du beskriver har egentlig absolutt ingenting med IT å gjøre. Det
har å gjøre med kundebehandling og å møte kunden på kundens
premisser. Alle yrker har samme problem. IT-bransjen er fremdeles
ganske ung, og det er ikke alle som har et bevisst forhold til dette
enda. Det samme gjelder estimater, prosjektledelse og andre disipliner
som ikke går direkte på det å kverne ut programkode. Jeg tror at
ansatte i IT-bransjen i løpet av ti-tyve år vil være nødt til å ta tak
i disse disiplinene. De som ikke vil være med på den karusellen tror
jeg vil slite med å holde på en jobb.
Jeg skjønner jo at jeg ikke har klart å kommunisere meningen min til
deg. Det får jeg ta på min kappe. Du er heldigvis ikke en kunde av
meg, så jeg tror ikke jeg gidder legge mye mer energi i å fortelle deg
hva jeg mener.
Geir
Joachim Lous
> Hvis man vet hvordan man skal håndtere situasjonen, er det idiotisk å
> bruke exceptions,
Langt ifra. Å bruke exceptions til normal kontrollflyt kan i en del
tilfeller være en elegant løsning der koden ellers ville blittt ganske
hårete. Men det stemmer at det ikke var derfor de ble oppfunnet.
--
+-------------------------------------------------------------------------+
|Brett ut og bøy helt tilbake. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Joachim Lous
> Joachim Lous <address...@example.net> writes:
>
>> I no.fag.spraak.fagord skrev Markus B. Krüger <mar...@pvv.org>:
>>
>> > Er det, eller var det, vanlig å implementere unntakshåndtering i
>> > programmeringsspråk med avbrudd?
>>
>
> Her spurte jeg ikke om implementasjonen av OSet, men hvordan man
> implementerte håndtering av unntak i programmeringsspråket (exceptions
> i C++ og Java, sikkert mange andre navn i andre språk).
Og svaret er at i de språkene som var kurrante på PC i DOSs storhetstid
var harwareunntak den makanismen man hadde.
--
+-------------------------------------------------------------------------+
|Kun for mineralvann. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Joachim Lous
> Når jeg tenker meg om så kjenner jeg
> faktisk ingen som bruker ordet 'unntak' i stedet for 'exception'.
Næh, men det var en stund alle som visste noe konsekvent sa sa "computer"
og "printer" og "monitor" også. Nå er det ingen som reagerer om du sier
"maskin", "skriver" og "skjerm".
Men for ordens skyld: jeg er ikke blant de som synes det er "syndig"
å bruke de engleske uttrykkene direkte innenfor faget. Men synes det er
morsomt når man finner noe som sitter sånn noenlunde naturlig.
--
+-------------------------------------------------------------------------+
|Gravide og ammende bør avtale bruk med lege. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Joachim Lous
> Joachim Lous <address...@example.net> writes:
>
>> I no.fag.spraak.fagord skrev Markus B. Krüger <mar...@pvv.org>:
>>
>> > Er det, eller var det, vanlig å implementere unntakshåndtering i
>> > programmeringsspråk med avbrudd?
>>
>> Hele MS-DOS var implementert som avbrudd. [...]
>
> Her spurte jeg ikke om implementasjonen av OSet, men hvordan man
> implementerte håndtering av unntak i programmeringsspråket (exceptions
> i C++ og Java, sikkert mange andre navn i andre språk).
Og svaret er at i de språkene som var kurrante på PC i DOSs storhetstid
var harwareavbrudd den makanismen man hadde. Men da som eksplisitte kall,
ikke som en del av språket.
Kjetil Torgrim Homme
>
> Exception handling (jeg er motstander av oversettelser) [...]
"exception handling" er eit grensetilfelle og kanskje knapt nok det,
men ord som glir over i daglegtalen bør ha ei norsk språkdrakt, altså
ha fylgje norske bøyingsmønster nokonlunde naturleg. korleis ville du
bøye "file"? "fil" er ikkje ideelt, men det er betre enn "file".
(ellers er eg einig i det du skriv, sjølv om eg prøver å skrive
britisk engelsk sjølv.)
--
Kjetil T.
Geir Harris Hedemark
> Og svaret er at i de språkene som var kurrante på PC i DOSs storhetstid
> var harwareavbrudd den makanismen man hadde. Men da som eksplisitte kall,
Softwareinterrupter, vær så snill. Konkret var INT-instruksjonen et
glorifisert subrutinekall.
Hardwarevarianten er ting som kommer utenfra via ledninger.
Geir - HW-tryne
Erik Naggum
| Hvis man vet hvordan man skal håndtere situasjonen, er det idiotisk å
| bruke exceptions,
* Joachim Lous
| Langt ifra. Å bruke exceptions til normal kontrollflyt kan i en del
| tilfeller være en elegant løsning der koden ellers ville blittt ganske
| hårete. Men det stemmer at det ikke var derfor de ble oppfunnet.
Har du noen eksempler på slike tilfeller?
[ no.fag.spraak.fagord fjernet ]
--
Erik Naggum, Oslo, Norway | HTML mail is discarded unread | 2004-120
Erik Naggum
| korleis ville du bøye "file"? "fil" er ikkje ideelt, men det er betre
| enn "file".
Siden «file»_en kommer fra «filare»_la som igjen kommer fra «filum»_la
som betyr «tråd»_no og henviser til hvordan man organiserte dokumenter
i middelalderen ved å sy dem sammen tilsvarende det som ble bokbinding
og engelsk har laget substantiv av verbet på vanlig manér, er det god
grunn til se å bruke «fil»_no, også. Det er tilogmed nesten idéelt.
--
Erik Naggum, Oslo, Norway | HTML mail is discarded unread | 2004-120
Erik Naggum
| Jeg skjønner utmerket godt dem som foretrekker at man ikke oversetter
| slike uttrykk. Men jeg har en liten hang til språklig estetikk --
| også på norsk.
Da håper jeg du er rette person å gjøre oppmerksom på at det er helt
vilt misforstått å oversette «exception»_en til «unntak»_no, og man må
instrueres spesielt i hva dette påståtte «unntaket» har med dataflyt
og kodeflyt å gjøre.
Hvis man først skal oversette det, er «innvending»_no langt nærmere
den tilsiktede engelske betydningen.
Erik Naggum
| Unnskyld? Er du *littegranne* følsom i dag?
Hvis han er det, hvorfor er det din oppgave å terge ham ytterligere?
Jon Haugsand
> * Jon Haugsand
> | Jeg skjønner utmerket godt dem som foretrekker at man ikke oversetter
> | slike uttrykk. Men jeg har en liten hang til språklig estetikk --
> | også på norsk.
>
> Da håper jeg du er rette person å gjøre oppmerksom på at det er helt
> vilt misforstått å oversette «exception»_en til «unntak»_no, og man må
> instrueres spesielt i hva dette påståtte «unntaket» har med dataflyt
> og kodeflyt å gjøre.
>
> Hvis man først skal oversette det, er «innvending»_no langt nærmere
> den tilsiktede engelske betydningen.
Hmm, det høres ikke greit ut, men det er kanskje bare en vane.
Jostein Berrefjord
> Softwareinterrupter, vær så snill. Konkret var INT-instruksjonen et
> glorifisert subrutinekall.
Joda. Men glorifiseringen omfatter å sette CPUen i *priviligert modus*
- på de aller, aller fleste maskiner er dette *eneste* måten overhodet
å kontrollert gå fra upriviligert til priviligert modus. Dette er
faktisk Den Essensielle Hensikten med internavbrudd. Selv om de fleste
maskiner i dag også gjør masse kontekst-lagring, er *det* noe som kunne
vært gjort av avbruddsrutina. Det er det ikke å sette priviligert modus.
Du *kunne* fått til det samme uten INT (eller hva det nå heter på de
ulike maskinarkitekturene) hvis programmet istedet sendte ut en eller
annen dataverdi på en ut-port som var kortsluttet til en ekstern
avbruddslinje. Og det er altså det man har gjort internt i CPUen: I stedet
for rotet med ekstra ledninger og tull har man laget en egen output-
instruksjon til en dedisert port som er loopet tilbake til avbruddslinja.
Det er kanskje ikke så fantastisk imponerende i seg selv. Men selv noe
så enkelt som en liten kortslutning gjør underverker i å skille mellom
operativsystem og brukerprogrammer.
Joachim Lous
> Joachim Lous <address...@example.net> writes:
>> Og svaret er at i de språkene som var kurrante på PC i DOSs storhetstid
>> var harwareavbrudd den makanismen man hadde. Men da som eksplisitte kall,
>
> Softwareinterrupter, vær så snill.
OK, bomma litt på termen der. Det jeg mente var at man faktisk går ut
og bruker hardware-features som interruptkontrolleren og interupt-linja
til CPUen, ikke bare fancy kontrollflyt i språket.
--
+-------------------------------------------------------------------------+
|Må ikke brukes i mikrobølgeovn. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Joachim Lous
> det er helt
> vilt misforstått å oversette «exception»_en til «unntak»_no,
Kan du forklare?
--
+-------------------------------------------------------------------------+
|Server avkjølt. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org
Jostein Berrefjord
> Da er det det brukeren gjør som bør være fokus, ikke hvordan du
> programteknisk gjør noe med feilen.
> "Håndtering av feilsituasjonen". Det er alt brukeren følger han
> trenger å vite.
Det er helt åpenbart at vi to har fullstendig ulik måte å forholde oss
til kunder på. Når jeg setter bilen min inn på verksted, er det *min*
bil mekanikeren reparerer, det er *jeg* som betaler for det. Hvis mannen
på verkstedet sier at "Jeg har reparert den - det er alt du trenger å vite"
da finner jeg meg et annet verksted neste gang. Jeg har overhodet ikke
peiling på hva som må gjøres for å skifte en startmotor, men da jeg betalte
fem tusen kroner fordi mannen påstod det var nødvendig, følte jeg meg
adskillig mer vel da han fortalte det, enn om han bare hadde sagt at
"Jeg har reparert bilen".
Jeg ser på datasystemer på samme måte. Det er *kunden* sitt system, ikke
mitt, selv om kunden ikke skjønner mer av det enn hva jeg skjønner av
bilmotorer. Og det er kunden som *betaler* meg.
Jeg har satt mye inn på å forholde meg til kunder på kundens premisser -
f.eks. kommunisere i et språk kunden forstår, bruke kundens begreper.
Og det har gitt betydelig positive effekter. Først og fremst *tillit*,
på samme måte som bilmekanikeren som bruker ti minutter på å vise meg
den gamle startmotoren med de nedslitte delene, til tross for at han
selvfølgelig skjønner at jeg er fullstendig uttafor når det gjelder bil.
Ikke bare styrker sånt kundeforholdet, men det er helt fundamentalt for
kommunikasjonen mellom meg og kunden - jeg forstår hva kunden vil, og
kunden forstår hva jeg foreslår.
> Den beste måten å kommunisere det du vil vil forandre
> seg avhengig av personen du snakker med. Jeg ser ikke det å diskutere
> fram et standard begrepsapparat som veldig fruktbart i den
> sammenhengen.
Det som er fruktbart er å ha et begrepsapparat som kunden kan forholde
seg til. Det er faktisk ganske essensielt!
> Joda, jeg har jobbet relativt lenge som supporthode i en tidligere
> tid. Det betyr ikke at jeg gjorde det til et poeng å fortelle brukerne
> om innmaten i det de brukte. Det er ikke det brukeren oppfatter som et
> problem, og han vil for det meste bare se tomt på deg og lure på når
> du skal slutte å fakturere ham for å prate skit.
Her er det et spørsmål om hva som er årsak og hva som er virkning. Hvis du
aldri har bevisst fokusert på å kommunisere i begreper som kunden forholder
seg til, er jeg ikke overrasket. Jeg forsøker å hele tiden ha det med meg
når jeg snakker med kunder, og jo bedre det lykkes, jo mindre tomme blikk
ser jeg. Med en del års erfaring blir tomme blikk sjeldnere og sjeldnere.
En selvfølgelig konsekvens av dette er at kommunikasjon med kunden ofte
bruker vagere definerte begreper enn jeg kunne ønske, og jeg må spørre, gå
litt som katten rundt grøten for å få indirekte hint om eksakt hva kunden
mener, ønsker seg, eller prøver å rapportere. Med litt erfaring går det
i hovedsak rimelig bra - mye bedre enn om jeg skulle prøve å tvinge kunden
inn i en for ham fremmed begrepsverden.
> De store
> konsulentselskapene gjorde forsåvidt store penger på å produsere
> timer, og dersom det er det du synes er gøy så kjør for all del den
> linja.
"Synes det er gøy"? Nei, men fordi det gir meg langt bedre mulighet for å
gi kunden et bedre produkt eller en bedre tjeneste, og det er med på å
bygge et tillitsforhold til kunden.
> Det du beskriver har egentlig absolutt ingenting med IT å gjøre. Det
> har å gjøre med kundebehandling og å møte kunden på kundens
> premisser. Alle yrker har samme problem.
Absolutt. På alle punkter. Men de fleste fag er så gamle at almuens språk
og det norske fagspråket er mye mer sammenfallende enn i IT-bransjen.
Dessuten: Både IT-folk og almuen er ofte så fokusert på at "dette er noe
helt nytt" at de ikke oppdager at det er det slett ikke... :-) Joda,
detaljene er nye, men begrepene er svært ofte utgamle. Vi setter på
nye navn på ting som allerede *har* et navn. "Vi avbryter sendingen
for å komme med en veimelding: Brua på E18 i Drammen har rast sammen".
"Vi interrupter programmet for å propagere et signal om at det er
utført en divisjon med null". Jeg gjetter på at da de første elektriske
motorene kom var det mange som fnøs av at de ble kalt "motorer" - de
var jo helt annerledes implementert en dampmotorer og eksplosjonsmotorer.
Men motor-bransjen(e) er så gammel at man har slått seg til ro med den
"upresise" betegnelsen "motor", så bruker vi heller en kvalifikator når
det er nødvendig å skille mellom bensin, diesel, elektrisk, damp osv.
> Jeg skjønner jo at jeg ikke har klart å kommunisere meningen min til
> deg. Det får jeg ta på min kappe.
Kanskje du bør skille mellom "kommunisere meningen til meg" og "få meg til
å slutte meg til din mening". Det virker ganske klart at vi er fundamentalt
uenig i hvordan vi som fagfolk bør forholde oss til kunder. Jeg streber
aktivt mot et annet mål enn det du forteller at du har, og jeg ser helt
andre reaksjoner enn de du rapporterer. Det *behøver* ikke være en
sammenheng, men det *kan* være det.
> Du er heldigvis ikke en kunde av
> meg, så jeg tror ikke jeg gidder legge mye mer energi i å fortelle deg
> hva jeg mener.
Tror ikke det er nødvendig, heller... :-)
Jostein Berrefjord
> Siden «file»_en kommer fra «filare»_la som igjen kommer fra «filum»_la
> som betyr «tråd»_no og henviser til hvordan man organiserte dokumenter
> i middelalderen ved å sy dem sammen tilsvarende det som ble bokbinding
> og engelsk har laget substantiv av verbet på vanlig manér, er det god
> grunn til se å bruke «fil»_no, også. Det er tilogmed nesten idéelt.
Heisann - plutselig forstod jeg hvorfor det heter "fil" i vei-sammenheng
også! En tråd av biler, altså :-) ... Skal vi trekke trådene(!) tilbake
til filer på datamaskinen som "en tråd av bytes" også? (Ja, det er en
nytolking som ikke går via bokbindingen, men det ville ikke vært helt
ulogisk likevel.)
Arne Georg Gleditsch
> Joda. Men glorifiseringen omfatter å sette CPUen i *priviligert modus*
Ikke under DOS, nei.
Arne.
Frode Vatvedt Fjeld
> OK, bomma litt på termen der. Det jeg mente var at man faktisk går
> ut og bruker hardware-features som interruptkontrolleren og
> interupt-linja til CPUen, ikke bare fancy kontrollflyt i språket.
Det er jo nettopp dette "software interrupts" _ikke_
gjør. Instruksjonen "int" er en flytkontrollinstruksjon noenlunde på
linje med "jmp", "call" etc.
--
Frode Vatvedt Fjeld
Markus B. Krüger
> I no.fag.spraak.fagord skrev Markus B. Krüger <mar...@pvv.org>:
> > Joachim Lous <address...@example.net> writes:
> >
> >> I no.fag.spraak.fagord skrev Markus B. Krüger <mar...@pvv.org>:
> >>
> >> > Er det, eller var det, vanlig å implementere unntakshåndtering
> >> > i programmeringsspråk med avbrudd?
> >>
> >> Hele MS-DOS var implementert som avbrudd. [...]
> >
> > Her spurte jeg ikke om implementasjonen av OSet, men hvordan man
> > implementerte håndtering av unntak i programmeringsspråket
> > (exceptions i C++ og Java, sikkert mange andre navn i andre
> > språk).
>
> Og svaret er at i de språkene som var kurrante på PC i DOSs
> storhetstid var harwareavbrudd den makanismen man hadde. Men da som
> eksplisitte kall, ikke som en del av språket.
Se de andre meldingene i denne tråden, hvor en av konklusjonene var at
unntak i programmeringsspråket (f.eks. "throw" i C++) nettopp *ikke*
er implementert gjennom eksplisitte kall til avbruddsrutiner ("int" og
venner).
Det er mulig vi snakker forbi hverandre her: når jeg sier unntak i
programmeringsspråket, mener jeg unntak et program selv genenerer ved
eksplisitte kall til "throw" eller lignende mekanismer. Jeg snakker
ikke her om unntak som oppstår på prosessornivå på grunn av ugyldige
minnereferanser, divisjon på null eller lignende, og som det
kompilerte programmet ikke kan fange opp på annen måte enn gjennom
avbruddsrutiner.
--
,------------------- Markus Bjartveit Krüger ---------------------.
' `
` E-mail: mar...@pvv.org WWW: http://www.pvv.org/~markusk/ '
)-------------------------------------------------------------------(
Frode Vatvedt Fjeld
> Det er mulig vi snakker forbi hverandre her: når jeg sier unntak i
> programmeringsspråket, mener jeg unntak et program selv genenerer
> ved eksplisitte kall til "throw" eller lignende mekanismer. Jeg
> snakker ikke her om unntak som oppstår på prosessornivå på grunn av
> ugyldige minnereferanser, divisjon på null eller lignende, og som
> det kompilerte programmet ikke kan fange opp på annen måte enn
> gjennom avbruddsrutiner.
Dette henger sammen på følgende måte, hvis man ser for seg et
skjematisk øyeblikksbilde av kontroll-stacken i det en throw skal
utføres:
1. Programmet starter
2. Etablerer en handler, f.eks try <try-prg> catch <catch-prg>
3. Programmet i <try-prg> kjører
4. En unormal situasjon oppstår
5. En "throw" til 2 skal utføres
Umiddelbart etterpå, når 5 er effektuert:
1. Programmet starter
2b. Programmet i <catch-prg> kjører
Så, punkt 4 involverer ofte--men ikke nødvendigvis--en exception,
enten det er eksplisitt (en "software interrupt" på x86) eller
implisitt som en division-by-zero, eller en ekte interrupt utenfra
(f.eks en watchdog-timer).
Punkt 5 involverer altså neppe "int"-instruksjonen i seg selv, men den
henger jo på en viss måte sammen med punkt 4, hvor "int" ofte er
involvert.
--
Frode Vatvedt Fjeld
Erik Naggum
| Hmm, det høres ikke greit ut, men det er kanskje bare en vane.
Naturligvis høres det ikke greit ut, siden folk er forvirret av at
«exception»_en er «unntak»_no i en hel rekke vanlige tilfeller, men
det heter f eks «å reise innvendinger»_no mot noe en ikke aksepterer,
akkurat som det heter «to raise exceptions»_en. «Exception»_en som
«protest»_no gir også mening i lys av «throw»_en og «catch»_en, men
det gir bare ikke mening i lys av tolkningen «unntak»_no. Det er kort
og godt ikke «unntak»_no man snakker om på engelsk i det hele tatt.
Spør noen andre som kan (amerikansk) engelsk om du ikke tror meg.
Erik Naggum
| Kan du forklare?
Sikkert, men hva trenger du forklaring på?
Siden du vil ha forklaring, hva med å forklare hvorfor «unntak»_no er
en fornuftig ting å snakke om i denne sammenhengen? Ville det i det
hele tatt ha vært mulig å bringe «unntak»_no på bane her om det ikke
var for at det var den ungdomsskole-engelsk for «exception»_en?
Erik Naggum
| Heisann - plutselig forstod jeg hvorfor det heter "fil" i vei-sammenheng
| også! En tråd av biler, altså :-) ... Skal vi trekke trådene(!) tilbake
| til filer på datamaskinen som "en tråd av bytes" også? (Ja, det er en
| nytolking som ikke går via bokbindingen, men det ville ikke vært helt
| ulogisk likevel.)
Det er ikke en nytolkning :) Dette er allerede opphavet til «fil»_no
om veibaner. «Filum»_la betyr «tråd»_no, men latin er det sproget som
i aller størt grad bruker konkrete uttrykk i overførte betydninger.
Således brukes «filum»_la også om utviklingen av temaet i en tekst, og
vi har mottatt det samme uttrykket i «den røde tråden»_no. «File»_en
som verb kommer allerede fra dette å ordne i rekkefølge, langs eller
med eller som en tråd, og så gjør engelsk bruk av det samme ordet for
å beskrive resultatet av handlingen, som så mange andre ganger.
Frode Vatvedt Fjeld
> [..] Ville det i det hele tatt ha vært mulig å bringe «unntak»_no på
> bane her om det ikke var for at det var den ungdomsskole-engelsk for
> «exception»_en?
Det ville jeg tro? F.eks skriver Kent M. Pitman i "Exceptional
Situations In Lisp":
It is useful to partition the description of a program's behavior
into two parts--what happens in normal situations, and what happens
in exceptional situations. This paper surveys the issues involved in
the description of program behavior during exceptional situations.
Det som står i kontrast til en normal situasjon er jo en unormal
situasjon, eller noe som skjer unntaksvis. Nå er det vel forskjell på
"an exception" og "an exceptional situation", men dette er ihvertfall
på samme banehalvdel.
<URL:http://www.nhplace.com/kent/Papers/Exceptional-Situations-1990.html>
--
Frode Vatvedt Fjeld
Gisle Aas
> Det er kort
> og godt ikke «unntak»_no man snakker om på engelsk i det hele tatt.
Jeg er ikke sikker på at jeg godtar dette. Du finner nok av eksempler
på "exceptions for exceptional conditions", f.eks. [1]. Siden vi
allerede bruker ordet "eksepsjonell", hvorfor ikke kalle det
"eksepsjon". Det gjør ihverfall order passe uvanlig.
[1] http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=77568
--
Gisle Aas
Leif Roar Moldskred
> Således brukes «filum»_la også om utviklingen av temaet i en tekst, og
> vi har mottatt det samme uttrykket i «den røde tråden»_no.
Litt avsporing her, men uttrykket "en rød tråd" kjem vel ifrå legenda
om Minotauren, og har vel ikkje noke med "filum" å gjere?
--
Leif Roar Moldskred
Erik Naggum
| [..] Ville det i det hele tatt ha vært mulig å bringe «unntak»_no på
| bane her om det ikke var for at det var den ungdomsskole-engelsk for
| «exception»_en?
* Frode Vatvedt Fjeld
| Det som står i kontrast til en normal situasjon er jo en unormal
| situasjon, eller noe som skjer unntaksvis. Nå er det vel forskjell på
| "an exception" og "an exceptional situation", men dette er ihvertfall
| på samme banehalvdel.
Du nærmer deg historien til ordet «exception» her, sannsynligvis uten
å vite om det. Som så mange andre ganger når man oversetter puns, må
man forstå at norsk har ikke den samme etymologien for de samme ordene
som engelsk har, og særdeles åpenbart blir dette når man snakker om
helt andre ord.
«Except»_en har en opprinnelig historie som «ta ut»_no, men norsk har
ikke holdt på denne ordbruken i den i mange ledd overførte betydningen
av dette ordet på latin og engelsk. Et «unntak»_no er utelukkende noe
som skiller seg ut fra mengden. En «exception»_no er en hel rekke
forskjellige ting, og spesielt har det utviklet seg gjennom å beskrive
en persons karakter som «without exception»_no, som senere ble til at
«exception»_en /selv/ var noe «objectionable»_en (som har sin egen
historie), i det Harry Bloom kaller «creative misprision»_en. Norsk
har ikke valgt denne måten å betrakte det å unnta noe eller unntak på.
Forøvrig har «exceptional»_en akkurat den samme tvetydigheten som
«exception»_en, og man kan like lite oversette alle tilfeller av
«exceptional»_en med «unntaksvis»_no (o.l.) som man kan oversette alle
tilfeller av «exception»_en med «unntak»_no. F eks har man uttrykk
som «take exception»_en som definitivt /ikke/ blir «ta unntak»_no (med
mindre man er oversetter for TV3 eller TVNorge, da).
Erik Naggum
| Du finner nok av eksempler på "exceptions for exceptional conditions",
| f.eks. [1]. Siden vi allerede bruker ordet "eksepsjonell", hvorfor
| ikke kalle det "eksepsjon". Det gjør ihverfall order passe uvanlig.
Men det finnes ingenting i norsk som tyder på at «eksepsjon»_no skal
være noe frastøtende eller direkte galt.
Hvordan skal man fortelle folk som ikke vil lytte at ord ikke bare har
denotasjoner, men også konnotasjoner som ofte farver denotasjonene?
Nordmenn er beryktet i USA og UK for å tro at de forstår engelsk så
godt at de kan slutte å lytte til hvordan mennesker rundt dem bruker
de ordene de tror de kan. Det er på tide å slutte å være så jævlig
arrogant at man tror at bare det en selv allerede mener er riktig,
/kan/ være riktig.
Erik Naggum
| Litt avsporing her, men uttrykket "en rød tråd" kjem vel ifrå legenda
| om Minotauren, og har vel ikkje noke med "filum" å gjere?
Vel, hvilket sprog var legenden om Minotauren skrevet på, da?
Hvorfor kaller vi meldingshierarkiet i news «tråder»_no? Det er ikke
/bare/ fordi det heter «thread»_en på engelsk, men fordi vi allerede
har et fungerende abstrakt forhold til tråder. Derfor er dette ikke
noe «faguttrykk» som man må oversette på skrullete vis, men ord som
deler samme historie på flere sprog og som derfor kan oversettes uten
semantiske krumspring. Det er når ordets historie ikke gjenfinnes i
et annets ords tilsvarende historie at man møter problemer når man
skal oversette mellom sprog.
Som f eks når en av TV3s genier oversetter et skilt på en dør i Los
Angeles med teksten «No solicitors»_en til «Ingen advokater»_no. Å
klare å begå en så fantastisk sted- og historieløs oversettertabbe
tyder på et veldig «norsk» forhold til leseoppfattelsen av engelsk.
Det er det samme jeg ser når «exception»_en blir oversatt til det helt
malplasserte «unntak»_no i tilfeller hvor det klart ikke bare handler
om et unntak, men om /flere/ andre slags ekstraordinære begreper.
Markus B. Krüger
> mar...@pvv.org (Markus B. Krüger) writes:
>
> > Det er mulig vi snakker forbi hverandre her: når jeg sier unntak i
> > programmeringsspråket, mener jeg unntak et program selv genenerer
> > ved eksplisitte kall til "throw" eller lignende mekanismer. Jeg
> > snakker ikke her om unntak som oppstår på prosessornivå på grunn av
> > ugyldige minnereferanser, divisjon på null eller lignende, og som
> > det kompilerte programmet ikke kan fange opp på annen måte enn
> > gjennom avbruddsrutiner.
>
> Dette henger sammen på følgende måte [...]
Ja, dette har gått klart fram av diskusjonen tidligere.
> Punkt 5 [throw] involverer altså neppe "int"-instruksjonen i seg
> selv, men den henger jo på en viss måte sammen med punkt 4 [en
> unormal situasjon oppstår], hvor "int" ofte er involvert.
Ofte og ofte; det finnes mange implementasjoner av programmeringsspråk
der unntaksmekanismene *ikke* fanger opp maskinvareunntak, og der
disse enten må håndteres på annet vis (f.eks. signal()) eller
ignorereres (med systemkræsj eller vilkårlig oppførsel som resultat
dersom den unormale situasjonen skulle oppstå). For eksempel klarer
ikke C++-kode kompilert med g++[1] å fange opp minneaksessfeil eller
null-divisjon med "try ... catch".
FUT satt til no.it.programmering.diverse, siden dette ikke er en
terminologidiskusjon lenger.
[1] I det minste ikke med den utgaven jeg har tilgjengelig, med mindre
det finnes spesielle opsjoner jeg ikke har oppdaget.
Arvid Grųtting
> * Leif Roar Moldskred
> | Litt avsporing her, men uttrykket "en rød tråd" kjem vel ifrå legenda
> | om Minotauren, og har vel ikkje noke med "filum" å gjere?
>
> Vel, hvilket sprog var legenden om Minotauren skrevet på, da?
Det var gresk for meg.
--
Arvid
Erik Naggum
| Det var gresk for meg.
Sukk. Det er tydelig at folk som gir seg ikast med oversettelse
mellom to sprog ikke har filla peiling på hva oppgaven innebærer og
overhodet ikke bryr seg om faglige forbehold man må ta når man bruker
oppslagsverk og henfaller til den mest alminnelige betydningen av et
ord. Svært ofte er ordboksoversettelsen faktisk /gal/ fordi ordet
blir misbrukt på en kreativ måte og det er den intuitive betydningen
hos en velfødd og godt belest bruker av sproget man må gjenskape. Det
handler ikke bare om idiomer, men om dobbeltbetydninger, hentydninger,
andre forfatteres bruk av ordet i en lignende eller kontrasterende
sammenheng, stilistiske nivåer, tonen i teksten, etc. Oversettelse er
meget enkelt å gjøre dårlig, og meget vanskelig å gjøre godt, fordi
sprog faktisk ikke er klin like, bortsett fra forskjellige navn på
helt identiske mengder begreper i helt identiske hierarkier med helt
identiske historier.
Det er jævlig irriterende å forsøke å forklare folk noe som de burde
klare å tenke seg frem til på egenhånd hvis de konsentrerte seg, og
som de derfor burde klare å forstå når de blir forklart hvis de bare
kunne konsentrere seg littegrann mer enn dette evinnelige flåseriet
som så altfor mange på news synes er det eneste de kan tenkes å få
utav all deres kommunikasjon med andre mennesker.
Kan du forklare hva du forsøkte å si, hvis det ikke var å flåse? Hvis
du har problemer med å forstå at latin og gresk og overlevering av
mytene og litteraturen fra antikken har vært farvet av begge sprog,
som når /de/ innbyrdes har samme ordhistorie og betydningsspekter,
uten problemer kan oversette mellom hverandre, har du noen forslag til
hva jeg kan hjelpe deg med som du ikke burde forstå på egenhånd?
Leif Roar Moldskred
> Vel, hvilket sprog var legenden om Minotauren skrevet på, da?
Tja, eg er ikkje nokon historikar so eg veit faktisk ikkje kva
originale kjelder vi kjenner historia frå, men eg vil anta at kjeldene
nok fyrst og fremst er skrive på gamalgresk. Poenget mitt var vel at
akkurat uttrykket "ein raud tråd" nok har andre, og eldre, anar enn
det latinske "filum."
[SNIP]
> Det er det samme jeg ser når «exception»_en blir oversatt til det helt
> malplasserte «unntak»_no i tilfeller hvor det klart ikke bare handler
> om et unntak, men om /flere/ andre slags ekstraordinære begreper.
Eg er nok ikkje einig med deg. Mens eg ser meiningsforskjellen i den
ulike bruken av "exception", synest eg at den bruken av "exception"
som eit begrep innanfor programmering stort sett brukar ordet i
meininga "unntak" og ikkje i meininga "innvending."
For eksempel i "Java in a Nutshell", tredje utgåva, side 344: "An
Exception signals an abnormal condition that must be specially handled
to prevent program termination"
Eller frå Ada 95 Reference Manual: "An exception represents a kind of
exceptional situation; an occurrence of such a situation (at run time)
is called an exception occurrence"
Og frå "The C++ Programming Language" av Stroustrup, tredje utgåva,
side 357: "'Exception' is one of those words that means different
things to different people. The C++ exception-handling mechanism is
designed to support handling of errors and other exceptional
conditions (hence the name)."
Eg synst ikkje det passar å oversette "exception" med "innvending" i
noken av sitata over, og meinar at "unntak" er eit betre val.
--
Leif Roar Moldskred
Arvid Grųtting
> * Arvid Grøtting
> | Det var gresk for meg.
>
[...]
> Kan du forklare hva du forsøkte å si, hvis det ikke var å flåse?
At minotaur-myten var gresk. Jeg falt bare for fristelsen til å
blande en engelsk ordsmeds skuespill inn i det hele.
--
Arvid
Erik Naggum
| Tja, eg er ikkje nokon historikar so eg veit faktisk ikkje kva
| originale kjelder vi kjenner historia frå, men eg vil anta at kjeldene
| nok fyrst og fremst er skrive på gamalgresk. Poenget mitt var vel at
| akkurat uttrykket "ein raud tråd" nok har andre, og eldre, anar enn
| det latinske "filum."
Kjære vakre vene, da. Å forstå at det handler om konkret og abstrakt
betydning av ordet «tråd»_no og nøyaktig tilsvarende ord i mange sprog
slik at oversettelse mellom den bokstavlige og den overførte meningen
kunne bruke det samme ordet, var altså for meget forlangt.
| Eg er nok ikkje einig med deg.
Quelle surprise. Folk som er nødt til å vurdere enighet før de har
forstått hva andre mener, har som regel tungt for å forstå noe de på
forhånd har følt seg uenige i.
| Mens eg ser meiningsforskjellen i den ulike bruken av "exception",
| synest eg at den bruken av "exception" som eit begrep innanfor
| programmering stort sett brukar ordet i meininga "unntak" og ikkje i
| meininga "innvending."
|
| For eksempel i "Java in a Nutshell", tredje utgåva, side 344: "An
| Exception signals an abnormal condition that must be specially handled
| to prevent program termination"
Du har altså ikke noe forhold til «innvending»_no som gir mening for
deg i denne sammenhengen. Hvordan håndterer du en protest eller en
innvending, om ikke ved å svare på en unormal situasjon som må få
oppmerksomhet om du skal unngå at det du forsøker å få til mislykkes?
| Eg synst ikkje det passar å oversette "exception" med "innvending" i
| noken av sitata over, og meinar at "unntak" er eit betre val.
Har du overhodet forsøkt, eller er dette bare enda et automatisk svar
av typen «jeg ikke like, derfor du feil» som Usenet er stappfull av?
Erik Naggum
| Kan du forklare hva du forsøkte å si, hvis det ikke var å flåse?
* Arvid Grøtting
| Jeg falt bare for fristelsen til å blande en engelsk ordsmeds
| skuespill inn i det hele.
Det var å flåse, altså.
Joachim Lous
> Naturligvis høres det ikke greit ut, siden folk er forvirret av at
> «exception»_en er «unntak»_no i en hel rekke vanlige tilfeller, men
> det heter f eks «å reise innvendinger»_no mot noe en ikke aksepterer,
> akkurat som det heter «to raise exceptions»_en.
Jeg kjenner til den bruken, men jeg er ennå ikke overbevist om at det
er den som ligger bak programmeringstermen.
> «Exception»_en som
> «protest»_no gir også mening i lys av «throw»_en og «catch»_en,
Hvordan da?
> Det er kort
> og godt ikke «unntak»_no man snakker om på engelsk i det hele tatt.
> Spør noen andre som kan (amerikansk) engelsk om du ikke tror meg.
Det trenger jeg ikke; det er mer enn nok av språkmektige amerikanske
fagfolk som har skrevet om exceptions og ganske eksplisitt lagt
"unntak"-betydningen til grunn. Det kan selvsagt hende at akkurat de
jeg har lest har misforstått, men så er det i hvert fall ikke bare dumme
nordmenn som gjør det.
--
+-------------------------------------------------------------------------+
|Bruk ikke sammen med andre medisiner uten avtale med lege. |
+-------------------------------------------------------------------------+
Joachim Lous joachim(a)lous.org