wasefire

wasefire copied to clipboard

When calling the prelude with wrong arguments, instead of panicking without error message, an error message could describe the problem. For example when calling led::set() with an out-of-bound index.

Ideas:

• Trapping should be reserved for undefined behaviors (e.g. invalid pointers). The platform should return errors for everything else (index out of bound, no permission, etc).
• Prelude functions should propagate the error when the user could not have prevented it (e.g. a function is not implemented and doesn't provided an is_supported function).
• Prelude functions should panic on errors that the user could have prevented (e.g. out of bound index).
• All those behaviors (trap, panic, error) should be documented on the prelude functions in the appropriate section.

Sub-tasks:

• #463
• #464

Prelude functions should panic on errors that the user could have prevented (e.g. out of bound index).

Hey just to make sure I understand this point. By panicking do you mean using scheduling::abort somewhere in the applet? or panicking somewhere in the scheduler using log::panic!

For example, for dealing with an index out of bounds error on led::set. I assume we would have to get the out-of-bounds-error from here. Then,

• If we wanted to panic in the applet we would have to somehow push the error back to the applet and then call another scheduling::abort some where here ?
• panicking in the scheduler I believe would be as simple as just calling log::panic! here instead of sending the error back to the scheduler to trap here

I assume we would have to get the out-of-bounds-error from here.

Yes, we would need to return an error there instead of a trap. Then the prelude would simply unwrap the result (maybe it does do already) with a track_caller attribute for the panic location to be in the user code.

No need to call scheduling abort, that should be automatic when panicking.

Also we should never panic in the scheduler.