With modern Python Exceptions, you don't need to abuse .message, or override .__str__() or .__repr__() or any of it. If all you want is an informative message when your exception is raised, do this:

class MyException(Exception):
    pass

raise MyException("My hovercraft is full of eels")

That will give a traceback ending with MyException: My hovercraft is full of eels.

If you want more flexibility from the exception, you could pass a dictionary as the argument:

raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})

However, to get at those details in an except block is a bit more complicated. The details are stored in the args attribute, which is a list. You would need to do something like this:

try:
    raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
except MyException as e:
    details = e.args[0]
    print(details["animal"])

It is still possible to pass in multiple items to the exception and access them via tuple indexes, but this is highly discouraged (and was even intended for deprecation a while back). If you do need more than a single piece of information and the above method is not sufficient for you, then you should subclass Exception as described in the tutorial.

class MyError(Exception):
    def __init__(self, message, animal):
        self.message = message
        self.animal = animal
    def __str__(self):
        return self.message

I have a couple reservations here. In the provided example, CustomError is used as a snap-in replacement for ValueError. The error message already makes it clear where the error comes from, because it is set by the programmer. So the exception handler does not provide a lot of additional insight.

Should you even raise an exception in this case? I find that debatable, because you can easily prevent the error in the first place by checking the value. In a real scenario, you might want to perform even more checks.

That being said, raising an exception is useful when you want to add an entry to the error logs, or when you want some corrective action to take place, like a cleanup routine (even though a context manager or a Finally clause can take care of that).

Minor points

Some statements can be simplified just a little:

self.source_line = linecache.getline(self.file_name,self.line).strip()
        if not self.source_line:
            self.source_line = "<unavailable

Slightly more succinct:

self.source_line = linecache.getline(self.file_name,self.line).strip() or "<unavailable source>"

However, there is a possible flaw here. If linecache.getline returns None, then the .strip you are applying could fail and raise an exception. But wait, let's look at the docs, because I admit I am not familiar with this lib. Sounds like you are in the clear here:

Get line lineno from file named filename. This function will never raise an exception — it will return '' on errors (the terminating newline character will be included for lines that are found).

I believe the frame object properties eg f_lineno etc should all be present, so hopefully no surprises here.

Instead of:

self.file_name = "<unknown file>"
self.func_name = "<unknown func>"

I would use None as a value. That simplifies parsing, and makes it clear that the value is not initialized or not yet known. The programmer retrieving these values from the exception can still reformat the error message as desired.

In __repr__ you use self.__class__.__name__ to identify your class, good idea. You can do the same in the __str__ method.

Stack trace

In more complex situations, the full stack trace is really helpful to have the context of the error, so that the programmer can dig hard into the logs and fix the issue. Perhaps you should consider making it available as an option. The idea should be to add more context and insight, not suppress useful information.

If the intention is really to generalize usage of this class, as an all-purpose exception handler, this could be problematic because we may want to handle exceptions differently, depending on their type. Some exceptions are recoverable, like transient network errors, whereas other exceptions are more fatal and point to a flaw in the program that cannot be easily managed.