Design idea: Very early ideas about handle errors/exceptions in carbon using try/catch

[sirlordt]

This a are very early ideas about error handling in carbon

In my opinion and experiences how programmer of C/C++/Java/TypeScript/JavaScript the Exceptions are not need to be a class. Is more of sufficient a simple struct

Key points:

1. The Exception class is supported only by compatibility with C++
2. The C++ Exceptions are handled in your own and unique catch block
3. The catch block only accept Error struct and CPP.Exception. Preventing of create sub types to Error.
4. The Error/Cpp.Exception are not propagated to upper scopes like C++.
5. The keyword raise replace the thrown from c++
6. The keyword raise always must be inside of try/catch block.
7. The keyword raise is sugar syntax to if ( error.Code != NO_ERROR ) go to MyFunction_Catch. Prevent the if hell of go lang.
8. The keyword raise only accept one parameter of type Error.
9. In low level the catch block is a simple label.
10. The responsibility of propagate the Error to upper scopes is in the developer at you own convenience. Using the pattern of value/error struct, tuples, choice types or whatever, in the return type of function/method. Very similar to go lang.
11. The fixed size in memory of struct Error help to place in memory stack. No need heap allocation. Is very fast.
12. The fixed size of CallStack field prevent memory heap allocation, always must be 15 entries, used or not, later we can define the magic number.
13. Is lot of use full had a predictable memory fixed size errors.

//From the 1000 to 10000 is reserved to standard library of Carbon
let NO_ERROR: i32 = 0;
let E_DIVISION_BY_ZERO: i32 = 1000; 
let E_NULL_ACCESS_POINTER: i32  = 1001; 

// Avoid the complicated class exception hierarchy. Like C++, Java, C#
// Forcing to catch to only accept Error struct, and CPP.Exception class. No more no less
struct Error {
    Code: i32; //This align with the goals "errors are numbers"
    Message: String[ 255 ]; //Fixed size in memory of 255 chars
    CallStack: [CallStackFrame,15];  //In my experience a call stack of 15 elements is more enough to know what is happens
    CallStackCount: i8;  //The actual size of call stack
}

struct CallStackFrame {
    Line: i32;
    File: String[ 255 ];
    Address: i64; 
    //Any other data. But always following  the fix size in memory
}

fn DefaultNoError(): Error {

   //Trivial init of struct Error
   return { .Code = NO_ERROR, .Message = "", .CallStack = [], .CallStackCount = 0 };

}

fn MakeError( code: i32, message: String[ 255 ], capture_call_stack: bool ): Error {

  //Trivial init of struct Error. This can be crazy fast if not call stack captured. 
  // O even optimized to compile time.
  let error: Error = { .Code = code, .Message = message, .CallStack = [], .CallStackCount = 0  };

  if ( capture_call_stack == true  ) { //Ok capture the call stack. This process can be heavy

     //Capture the call stack 

  }

  return error;

}

//Custom errors start from 10001

let E_TRY_DIVISION_BY_ZERO: i32 = 10001;

//This examples not pretend be a syntax correct examples, just examples
fn TryDivisionByZero(  a: f64, b: f64 ): ( value: f64, error: Error ) {

 let result: ( value: f32, error: Error ) = { .value = 0.0, .error = DefaultNoError() };

  try { 

     if ( b == 0 ) {
  
         //Create a custom error, you can only use raise inside a try / catch block
        // to prevent the error "escape" to superior scopes
        //The true to end parameter indicate error capture the call stack
        raise MakeError( E_TRY_DIVISION_BY_ZERO, "Error trying to divide by zero", true ); 

     }

    result.value = a / b;

  }
  //Only 2 catch allowed. With type struct Error and/or CPP.Exception. No more types allowed in catch
  catch ( let error: Error ) { 

     //Handle error codes
     if ( error.Code == E_TRY_DIVISION_BY_ZERO ) { 

       //Return the error to superior scope in control way, like go/rust
       result.error = error;

     }

  }

  return result;

}

fn Main() {

   var ( value: f64, error: Error ) = TryDivisionByZero( 10, 0 );

  if ( error.Code != NO_ERROR ) { 

    Print( "Error to divide. Code: {}, Message: {} ", error.Code, error.Message  );
    PrintCallStack( error );

  } 

  Print( "Division result is {}", value );

  //Using another try/catch

  try {

    // If use raise before the error variable, carbon jump to catch
    // raise is syntax sugar to 
    // if ( error.Code != NO_ERROR )
    //  jump to catch label
    var ( value: f64, raise error: Error ) = TryDivisionByZero( 10, 0 );

    Print( "Division result is {}", value );

  }
  catch ( let error: Error ) {
  
     if ( error.Code == E_TRY_DIVISION_BY_ZERO ) { 

       Print( "Error to divide. Code: {}, Message: {} ", error.Code, error.Message  );
       PrintCallStack( error );

     }

  }

}

What about C++ Exceptions?

Here my idea.

Support the CPP.Exception only with additional catch

//This examples not pretend be a syntax correct examples, just examples
fn CPPException(  a: f64, b: f64 ): ( value: f64, error: Error ) {

 let result: ( value: f64, error: Error ) = { .value = 0.0, .error = DefaultNoError() };

  try {

      result.value = CPP.GenerateException( a, b );

  }
  // 2 catch, 1 to handle Carbon errors and 1 to handle C++ Exceptions
  // For the case this catch is optional
  catch ( let error: Error ) {  
   
     if ( error.Code == E_TRY_DIVISION_BY_ZERO ) { 

       Print( "Error to divide. Code: {}, Message: {} ", error.Code, error.Message  );
       PrintCallStack( error );

      result.error = error; //Pass the error upper scopes

     }     

  }
  //C++ catch all Exceptions, Required to handle C++ Exceptions
  catch ( let exception: CPP.Exception ) { 

     result.error = CPP.TranformToError(  exception  );  // CPP.Exception -> Carbon.Error

  }

  return result;

}

About the defering a null pointer, division by zero,

I think carbon need a generate a error by default and not only kill the app.

I used for c++ project the setjmp/longjmp to catch this kind execeptions.

Why not let to program die by default?. Because to some kind a http backend this default behavior can be exploited to make DOS attack. Shutdown the service.

//This examples not pretend be a syntax correct examples, just examples
fn NullPointerCatch(  a: Person* ): ( value: bool, error: Error ) {

   let result: ( value: bool, error: Error ) = { .value = false, .error = DefaultNoError() };

   // This try catch null pointer access and division by zero. 
   // Using signals in Linux/Mac, Windows Structured Exceptions in windows
   try { 

      let first_name: auto = a->FirstName; //Null access pointer 

      result.value = true;

   }
   catch ( let error: Error ) {  //Only one catch

    if ( error.Code == E_NULL_ACCESS_POINTER ) { 

       Print( "Ups!!!. Code: {}, Message: {} ", error.Code, error.Message  );
       PrintCallStack( error );

       System.Exit( -1 );  //Let the programmer decide if the program die o not.

     }     

   }

   return result;

}

fn Main() {

   var ( value: bool, _: Error )  = NullPointerCatch( null );

}

[L4stR1t3s]

Allowing only 1 exception would mean that you can't do this:

fn func1() {
    if (...)
        throw FirstException;
    if (...)
        throw SecondException;
}

fn func2() {
    try {
        func1();
    }
    catch ( FirstException ) {}
}

fn func3() {
    try {
        func2();
    }
    catch ( SecondException ) {}
}

You would need to rethrow specific exceptions you are not handling in every try catch block.

Also, exceptions would not be identifiable at compile-time. For example, if an exception is changed or removed, the compiler wouldn't be able to tell you about it:

...
throw Exception(3); // Changed from Exception(2)
...
catch ( e : Exception ) {
    if (e.Code == 2) {} // No compile error
...

...
throw ThirdException; // Changed from SecondException
...
catch ( SecondException ) {} // Compile error
...

Why not let to program die by default?

Software that controls a nuclear reactor for example should not simply shut down because a developer forgot to check for a division by zero. We can't guarantee human error will not occur when developing software, but we can and must do a better job than shutting down when it does happen.

Because to some kind a http backend this default behavior can be exploited to make DOS attack. Shutdown the service.

That would mean that attackers simply need to find a single exploit that divides by zero for example, and they can easily shut down the web service remotely.

[Tomttth]

try catch will need finally block as in java/javascript. This will come in handy when we are reading files and some exception is occurring during that time. we can give the syntax for closing file in finally. Also the exceptions which are not handled by catch should be rethrown. We can mention the throws in function like in java so that eventually the default handler would catch the exception or we can simply mention "rethrow e" at the end of the catch or finally block so that the function which is calling this function can handle the exception.

[sirlordt]

try catch will need finally block as in java/javascript.

The finally in my opinion is not needed because in any Error condition always is catched by the catch section.

Remember the error not propagated to upper scopes like c++.

The upper scope are noticed a error checking the error variable

 var ( value: f64, error: Error ) = TryDivisionByCero( 10, 0 );

  if ( error.Code != NO_ERROR ) { 
     ....
  }

Or

   //Using the raise keyword
   var ( value: f64, raise error: Error ) = TryDivisionByCero( 10, 0 );

Also the exceptions which are not handled by catch should be rethrown

My point is any error not handled by the catch can be passed to upper scope using the

result.error = error;

Or silent ignored. This simplifiy the error handling.

[L4stR1t3s]

Also the exceptions which are not handled by catch should be rethrown

How do you determine if a specific error is handled?

catch( e : Exception) {
    if (e.Code() == 0) { print( "error" ); };
    if (e.Code() >= 1 && e.Code <=5) { print( e.Message); };
    if (e.Code() % 123 == 75) {};
    functionThatHandlesErrors(e);
}

How can the compiler determine which error codes are handled and which ones aren't when exceptions are not identifiable at compile-time? The decision would have to be made at run-time, so when is an error code considered to be handled?

[Tomttth]

What I am saying is if the exception for some reason is not handled by catch block, it needs to be passed to outer scope or the calling function for handling it.

The second syntax mentioned in the above example is okay as it would pass the exception which was not caught by the try catch block of the called function to the scope of the calling function:

try {

// If use raise before the error variable, carbon jump to catch
// raise is syntax sugar to 
// if ( error.Code != NO_ERROR )
//  jump to catch label
var ( value: f64, raise error: Error ) = TryDivisionByZero( 10, 0 );

Print( "Division result is {}", value );

}
catch ( let error: Error ) {

 if ( error.Code == E_TRY_DIVISION_BY_ZERO ) {     

   Print( "Error to divide. Code: {}, Message: {} ", error.Code, error.Message  );
   PrintCallStack( error );

 }

}

[geoffromer]

I'm converting this to a discussion because it doesn't seem to be an issue that can be resolved with a commit in the near term.

[L4stR1t3s]

//From the 1000 to 10000 is reserved to standard library of Carbon

How do libraries know which range they can use? If you use several different libraries in your project, that each use several different dependencies themselves you might not even be aware of, how do you make sure error indices are unique? If they are not, then how would you be able to tell where an error comes from? Parse the call stack? That's a lot of additional code.

[sirlordt]

How do libraries know which range they can use? If you use several different libraries in your project, that each use several different dependencies themselves you might not even be aware of, how do you make sure error indices are unique?

I don't know!!!. Think you a solution for this "Problem".

If they are not, then how would you be able to tell where an error comes from? Parse the call stack? That's a lot of additional code.

This is not much different how java handle Exceptions. The only one big difference in my opinion is the error are not propagated to upper scoped level like C++/Java/JavaScript. The function PrintCallStack must be show where the error come in the last 15 entries of call stack.

This had advantages

1. No hidden paths in the code. raise keyword always is inside a try/catch block.
2. The responsibility to propagate the Error to upper scope level is in the developer a your own convenience.
3. The compiler not need crazy machine code to pass the exception to upper scope levels. This a pain point in performance of c++ exceptions.

[L4stR1t3s]

How do libraries know which range they can use? If you use several different libraries in your project, that each use several different dependencies themselves you might not even be aware of, how do you make sure error indices are unique?

I don't know!!!. Think you a solution for this "Problem".

Yes, don't have just 1 exception object. ;-)

Assuming there would be only 1 exception object, I guess every source of exceptions would have to have a unique identifier which would be stored in the exception object when an exception is thrown.
Using an index based system just causes the same issue this is trying to solve.
The name of the library is supposed to be unique, so maybe that could be used, although I thinkl there will be quite some practical issues with that as well.

If they are not, then how would you be able to tell where an error comes from? Parse the call stack? That's a lot of additional code.

This is not much different how java handle Exceptions. The only one big difference in my opinion is the error are not propagated to upper scoped level like C++/Java/JavaScript. The function PrintCallStack must be show where the error come in the last 15 entries of call stack.

15 is extremely low, considering what a callstack looks like when you use Qt for example.
What made you make the callstack size constant in the first place? I don't really see a reason why it couldn't be a dynamically allocated list here.

I don't think parsing the call stack to identify where an error comes from is feasible though. It's extremely verbose IMO and will break constantly all over the place because call stacks change when code changes.

Same for message being a fixed amount of characters, In don't see why it can't just be a dynamic length string. (btw: you defined an array of 255 strings in your code, not 255 chars)

And that still severely limits your options IMO. What if the exception is associated with a specific file, external process, hardware device, ... When an exception is thrown the correct way to handle it might be to try a file operation again, restart an external process, reinitialize a hardware device, ... Who knows what information might be needed to handle the exception correctly? Sure, you could add some data member variable where anything can be stored, but I prefer custom exception classes. In that case the available information is clearly defined and therefor more developer and IDE friendly, rather than a meaningless member variable that could be anything and requires converting to something you don't know without consulting the documentation or the code.

This had advantages

1. No hidden paths in the code. raise keyword always is inside a try/catch block.

2. The responsibility to propagate the Error to upper scope level is in the developer a your own convenience.

3. The compiler not need crazy machine code to pass the exception to upper scope levels. This a pain point in performance of c++ exceptions.

To me, 2 and 3 really just mean moving the problem from the compiler to the developer, resulting in more verbose code, more things that could break and less readable code.

[geoffromer]

In case you haven't seen them, you might want to take a look at the all errors are values principle, and p0301, the underlying proposal for that principle.

One thing that's not clear to me is how you envision handling errors within expressions. For example, suppose I have code like z = x/a + y/b;, and I want to rewrite it to use TryDivisionByZero instead of / -- what would that look like?

   var ( value: f64, error: Error ) = TryDivisionByZero( 10, 0 );

This looks like it models TryDivisionByZero as returning a tuple consisting of a value and an error, but conceptually it returns a value or an error, right? This seems like a good use case for a choice type, and in fact it's one of the main use cases they were designed for.

// Forcing to catch to only accept Error struct, and CPP.Exception class. No more no less

Why can't users define their own error types? Notice in particular that this restriction makes it vastly harder to design the Error type, because now it needs to be flexible enough to handle every possible use case, not just the most common ones.

[sirlordt]

One thing that's not clear to me is how you envision handling errors within expressions. For example, suppose I have code like z = x/a + y/b;, and I want to rewrite it to use TryDivisionByZero instead of / -- what would that look like?

mmmm. Good question. I don't know. Maybe you can help me to think a solution!!!.

Why can't users define their own error types? Notice in particular that this restriction makes it vastly harder to design the Error type, because now it needs to be flexible enough to handle every possible use case, not just the most common ones.

std::exception is a base class for all C++. Pretend be compatible all most kind of sub types of exception class.

Additional keep Error simple struct with predictable size help to allocate in the stack.

The another kind of thrown for example:

try {

   thrown "My error"; 

}
catch ( std::string ex ) {

}

Is really hard to handle and not idea how fix that.

With this discussion is a pretend opening the talk of what kind of idea are around this critical topic.