Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handling #1

Open
Marakai opened this issue Oct 28, 2021 · 9 comments
Open

Error handling #1

Marakai opened this issue Oct 28, 2021 · 9 comments
Labels
IDEA IDEA ON IMPROVING THE LANG

Comments

@Marakai
Copy link

Marakai commented Oct 28, 2021

It is not clear whether BONZA and FAIR DINKUM are reserved words.

Also, whether it's FAIR DINKUM or FAIRDINKUM!

@zackradisic
Copy link
Owner

zackradisic commented Oct 28, 2021

You are exactly right. I suggest we use FAIR DINKUM! and have that and BONZA as alternates for the true boolean.

Alternatively I was considering using them as the success variant of an error handling monad like Rust's Result<T, E> / Haskell's Either L R. And then use STREWTH! for the error variant.

So something like this:

// define a functionn that can fail or succeed
THE HARD YAKKA FOR fallibleFunction IS (shouldFail) <
    YA RECKON shouldFail IS A <
        YEAH, NAH ~ BAIL BONZA "bonza mate!"; // successful return
        NAH, YEAH ~ BAIL STREWTH "fark!"; // error
    >
>

// then you can use pattern matching to handle the success/fail cases
YA RECKON fallibleFunction(YEAH, NAH) IS A <
    BONZA x     ~ GIMME "the function succeeded mate: "  + x;
    STREWTH x   ~ GIMME "the function failed: " + x;
>

@jwfxpr
Copy link
Contributor

jwfxpr commented Oct 28, 2021

I came here to suggest STREWTH! for error handling 👌😆

Edit: Alternatively, GIT FAAARKED

@timshepherd-academy
Copy link

timshepherd-academy commented Oct 28, 2021

I'd like to suggest replacing ChuckSomeDice name with ComeInSpinner...or maybe using that as a alias 😄

@zackradisic zackradisic added the IDEA IDEA ON IMPROVING THE LANG label Oct 29, 2021
@howsitcohendevelopment
Copy link

Good work getting this up and into the ether @zackradisic

Really want to see the WHATYARECKON<> AAHSHELLBERIGHT <> try catch block implemented

@zackradisic
Copy link
Owner

zackradisic commented Oct 29, 2021

@howsitcohendevelopment thanks m8! Couldn't have done it without the amazing and hilarious ideas you guys came up with.

Totally forgot about WHATYARECKON<> AAHSHELLBERIGHT <>. I think that's preferable over the FP monad approach I mentioned until we have a type system.

How should one throw an error? I think STREWTH <value> is pretty good, any other ideas?

@jwfxpr
Copy link
Contributor

jwfxpr commented Oct 29, 2021

+1 for STREWTH <value>.

@zackradisic zackradisic changed the title Unclear language definition Error handling Oct 29, 2021
@timshepherd-academy
Copy link

var ex = new JEEZLOUISE("that exception is a dog breakfast");

or actually,

var ex = new DOGSBREAKFAST("guess yer up shits creek");

(sorry...coming from C# here 😄 you can convert the wording haha)

@jwfxpr
Copy link
Contributor

jwfxpr commented Oct 30, 2021

@timshepherd-academy In C# terms, the proposed STREWTH <error> is roughly equivalent to throw new Exception(<error>). So, e.g., for a null check:

THE HARD YAKKA FOR strewthItsNullMate IS (thisParam) <
    YA RECKON thisParam = BUGGER ALL ? < STREWTH "YA GAVE ME BUGGER ALL YA DRONGO"; >
>

That YA RECKON statement is basically equivalent to this very familiar null check pattern:

    if (thisParam == null) { throw new Exception("YA GAVE ME BUGGER ALL YA DRONGO"); }

We haven't yet clarified exactly what the <error> value would be, most likely a numeric error code rather than a string like in these examples, or both. There's a plan (see todo list at #5) to introduce try ... catch with WHATYARECKON < \* try block *\ > AHHSHELLBERIGHT < \* catch block *\ > which will be much easier to implement using numeric codes for catching error types.

There's a discussion (#3) on how to import external files and modules into your code, which would allow for both standardized error defines using, for example, a stderror module which provides standardised error codes, which you'd use something like (import syntax still under discussion, this is just an example):

IMPOHT MAATE FROM ME MODULE stderror // using stderror as MAATE;

THE HARD YAKKA FOR strewthItsBuggerAll IS (thisParam) <
    YA RECKON thisParam = BUGGER ALL ? < STREWTH MAATE.BUGGERALLPARAMETER; >
>

Which would chuck a BUGGERALLPARAMETER strewth.

You also then have the option to define your own error codes across your modules, in your own module, say, mystrewths.aussie which defines, e.g., DOGSBREAKFAST as a user-defined error for invalid parameters:

IMPOHT MAATE FROM ME MODULE stderror // using stderror as MAATE;
IMPOHT MAAATE FROM ME MODULE "mystrewths" // using "mystrewths" as MAAATE;

// Chucks a strewth for any non-boolean parameter
THE HARD YAKKA FOR strewthItsADogsBreakfast IS (thisParam) <
    YA RECKON thisParam IS A <
        BUGGER ALL ~ STREWTH MAATE.BUGGERALLPARAMETER;
        YEAH, NAH ~ BAIL;
        NAH, YEAH ~ BAIL;
        dogsBreakfast ~ STREWTH MAAATE.DOGSBREAKFAST; >
>

@zackradisic
Copy link
Owner

@jwfxpr great ideas, I really like the concept of having errors as values which is what Go and Rust do. Then we can also pattern match on errors:

IMPORT MAATE FROM ME MODULE "mystrewths"

WHAT YA RECKON <
   strewthItsADogsBreakfast(x)
> AHHSHELLBERIGHT(fuck) <
    YA RECKON fuck IS A <
        MAATE.BUGGER_ALL_PARAMETER ~ GIMME "fuckin' hell mate, pass somethin in";
        MAATE.DOGS_BREAKFAST       ~ GIMME "FAARK!";
        buggeredIfIKnow            ~ GIMME "carn";
    >
>

@zackradisic zackradisic mentioned this issue Oct 30, 2021
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
IDEA IDEA ON IMPROVING THE LANG
Projects
None yet
Development

No branches or pull requests

5 participants