Warn that model.unit.is_leader() can raise an exception
See original GitHub issueWe should add a note that the is_leader()
method can return an exception.
is_leader()
is called when a charm is attempting to determine if it will be able to invoke hook tools that are restricted to leaders, presumably to avoid the possibility of exceptions.
I would personally be more comfortable with logging the problem at WARN level and returning False
or None
if it’s called in the context of a remote application.
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (8 by maintainers)
Top Results From Across the Web
pytest: How to force raising Exceptions during unit-testing?
In my python code, I am expecting exceptions could possibly be raised after calling method requests.Session.request() , for example these:.
Read more >install hook fails on public or private address not found
The easyrsa unit looks to be running on machine 1. Logs from machine 1 show the machine agent starting. One of the things...
Read more >A JML Tutorial
Java Modeling Language ... m(). Gary T. Leavens (UCF). JML Tutorial. Fall 2007 ... ESC/Java2: Warn about likely runtime exceptions and violations.
Read more >Messaging Endpoints - Spring
By setting this attribute to true , you can define exactly one global default poller. An exception is raised if more than one...
Read more >Release Notes - ZooKeeper - Version 3.5.10
doAs() causes zk client to falsely assume that the server did not ... ZOOKEEPER-4377 - KeeperException.create has NullPointerException when ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I understand the rationale here. @jameinel’s example makes it clear that charm authors can’t stumble into the exception, and thus the error state. But…
An unhandled exception could be very costly to someone deploying a charm. A non-zero exit is very difficult to recover from in a live model. Unless you are writing a charm, the error state is very difficult to resolve. Accordingly, we should only raise exceptions if we genuinely believe that we can’t proceed.
In this case,
is_leader()
could easily returnFalse
in cases where its argument is invalid. Callers would be well behaved and the model would progress happily.So yes, raising an exception is the perfect thing to do from a Python-perspective. But charms operate in a much different context to most Python programs.
is leader does return a boolean.
It just raises an exception if you do:
unit = self.model.get_unit(‘other-app/0’) unit.is_leader()
self.unit.is_leader()
just returns a boolean.
On Mon, May 11, 2020, 20:55 jamesbeedy notifications@github.com wrote: