Hi assembleros & assembleras,Is it
reasonable/
meaningful/
feasible to implement in Assembly the
try/catch exceptions feature that some high-level languages offer?
For examples:Python"""
A basic exception block for error(s) handling.
It is possible to declare multiple `except` statements for each
errors type we want to catch.
Variables
------------
fd: _io.TextIOWrapper
A file object
errmsg: string (object)
The error message to output
"""
try:
fd: TextIO = open("./path/to/file.txt", 'r')
# Some code with fd...
fd.close()
except FileNotFoundError:
errmsg: str = f"Error {errno.ENOENT}: {os.strerror(errno.ENOENT)} {fd}"
raise FileNotFoundError(errmsg)
# End of example (Python 3)
C++/.**
* stdc++ >= 11
*/
std::fstream ifs; // input file stream object (in `fstream` header)
try
{
ifs.open("./path/to/file.txt", std::ios::in);
ifs.exceptions(ifs.failbit); // std::ios::failbit
/* Some code with ifs */
ifs.close();
}
catch (const std::ios_base::failure& ex)
{
std::cerr << "Error code: " << ex.code() << ", Error message: " << ex.what() << 'n';
}
You obviously understand that
as a beginner I am not at all fluent in Assembly, I can barely babble a few lines of code, even some sequence of onomatopoeia... so maybe my question is incongruous(1), or worst: preposterous, in the (n)asm context.
Perhaps you would be inclined to tell me: "
Wow, slow down, you inconsequent evanescent nitwit dreamer! Learn the very basics first, then you'll dive in more complexe topics."
To that I would answer: yeah, I agree... partially, because these kind of questions helps me understand the core concepts of the language.
For example, while searching about printing to the screen, I was very disappointed when I discovered that in Assembly, most of the time many things are done via sytem calls; initially I thought that the language in the first place was a mean to control directly the hardware, independently from the OS, and then I learned about
Real/Protected Modes, and how the system and the kernel play a major role in the process of producing and running "executable binary strings".
From misconceptions to clarity and understanding there are some steps that require (at least for me) an approach trying to embrace a more holistic view (2).
(1) Lets go to
incongruous speed right now!
(2) As well as the need for the provision of an adequat toolchain (more pragmatically, with the aim of moving from theory to practice), but that's another subject.
From beginner to master, the learning curve is more a 3 (or more) dimensions one than a 2D...
