#🔒 Unconventional Exception Handling Techniques in Python

49 messages · Page 1 of 1 (latest)

timber beacon
#

I am currently investigating alternative methods for intercommunication between different components within a project by leveraging exception raising and capturing mechanisms.

While I acknowledge that this approach diverges from the conventional use of exceptions primarily intended for error handling, I am exploring its potential validity.

To illustrate, envision a scenario where an exception is raised within a file named file1.py:

try:
  raise CustomError
except CustomError as exc:
  # Obtain attributes from file2.py and file3.py
  print(exc.attr2, exc.attr3)

This exception is subsequently accessed and managed in file2.py and file3.py:

# file2.py
error: CustomError
error.attr2 = "test!"

# file3.py
error: CustomError
error.attr3 = "test!"

Essentially, I am seeking a method to govern the propagation of Python's exception handling flow, as well as the normal execution flow, facilitating execution to continue after the raise keyword is invoked.
Additionally, I aim to establish a mechanism to handle exceptions raised once, yet handled multiple times throughout the project.

While I acknowledge that historically, such techniques have not seamlessly aligned with Python's exception handling paradigm, I am enthusiastic about exploring innovative approaches.

If you happen to be exploring possibilities in this domain, I am keen to engage in further discussion and exchange insights.

hushed portalBOT
#

@timber beacon

Python help channel opened

Remember to:

  • Ask your Python question, not if you can ask or if there's an expert who can help.
  • Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
  • Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.
fresh kernel
#

Can you say more about why you are exploring this unconventional idea?

timber beacon
#

I'm trying to know more about it.
Perhaps, if this idea works, I may make some things easier.

#

In addition, knowing it won't harm.

fresh kernel
#

why not use the existing methods? Are they lacking in some way?

timber beacon
#

Not really. I am trying to, for example, raise a specific error, which was handled to execute a specific function/command.

#

There's no reason to do so.

#

I could do the way you ask but should I explore these ways, it will become more easier.

#

I would appreciate if you could help me explore this particular behavior.

#

:)

fresh kernel
#

I'm sorry, but i don't see the reason for it, and i don't think it will make things easier, so I'm not sure how to help.

timber beacon
#

I'm sorry for my inclarification.

#

Let me explain.

#

Well, I have a script with a running event loop.

#

I have an error handler in a separate file, and my main code in another file.

#

In my main file I have many functions that use almost same functionality.

#

I thought I could remove redundancy by raising errors which will be handled in the error handler and then utilized to do specific commands.

#

I could have made a mutual function instead and then called it at anywhere.

#

But I thought raising an exception to provoke a command would be more convenient.

#

I encountered two issues:
1 -> Since Python stops the normal execution flow at an exception, what's after raise will be ignored.
2 -> If I try-except the exception that I just raised, then it won't reach to the error handler in the other file.
3 -> If I don't try-except, (1).

#

Yes, they are two not three.

fresh kernel
#

do you need to change #1? Because you can't.

timber beacon
#

(1) won't be important if (2) works.

#

(1) won't be necessary if (2) works

#

Let's say I do in:

# main.py
try:
  raise MyCustomError
except MyCustomError as e:
  print(e.attrs) # None

# err_handler.py
error: MyCustomError
error.attrs = ()
fresh kernel
#

There's no reason to raise an error and catch it immediately.

timber beacon
#

Exactly.

#

Because it's illogical.

#

What I am trying to do is to receive something similar to a callback from the error handler.

#

What it should be like:

print(e.attrs) # None, before reaching to the error handler.
print(e.attrs) # (...), after reaching to the error handler.
#

I haven't thought of a way to receive a signal or something similar to when the error has been handled.

#

Try-excepting the exception, I thought it would have worked, but it hadn't.

#

All it does is do nothing.

#

I thought the except: block would tell me what's after the error has been handled by the error handler.

#

What actually happens is that it's being executed before the error handler was called.

#

That's why I also asked about how to control python's exception propagation system.

#

It normally propagates to the nearest error handler.

#

I want it to propagate to a farther error handler before the nearest error handler.

#

I don't know if what I'm saying makes any sense. I apologize.

fresh kernel
#

you can't make the exception skip an except block. It sounds like you are trying to change the basics of how Python behaves. That would require changing the Python implementation. I don't think you want to do that.

timber beacon
#

I don't think too.

#

It was an idea.

#

It was not a very good idea.

#

I am going to resort to the convenient way of using a function and then to call it throughout the project, instead of error handlers.

#

Thank you for your time, sir.

#

!close

hushed portalBOT
#
Python help channel closed

This help channel has been closed and it's no longer possible to send messages here. If your question wasn't answered, feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.