Performance benchmarks:

Thanks for this PR. I think its still a bit premature. I don't agree with mesa.errors.py, and mesa.space is a bad choice to start with because it's about to be removed.

Also CellNotEmptyError is not a good name. I prefer Exception over Error. Also, the issue for at least discrete_space is not that the cell is not empty. Rather, It is that the cell is at capacity. So CellFullException might be more on point.

Thanks for the update. I think this is moving in a good direction.

What other generic exceptions should be replaced in mesa.discrete_space.

Thanks.
I have three additional candidates for replacement in mind within mesa.discrete_space (AgentMissingException, CellMissingException, and ConnectionMissingException).

I have posted the detailed breakdown and rationale for these additions in the main Discussion thread.

I have three additional candidates for replacement in mind within mesa.discrete_space (AgentMissingException, CellMissingException, and ConnectionMissingException).

Sounds good to me. Where possible, consider using the raise from syntax. For example, the key error cases could use this. Basically, this wraps the source (key error) inside our more informative custom exception. Please feel free to add these to this PR.

I have three additional candidates for replacement in mind within mesa.discrete_space (AgentMissingException, CellMissingException, and ConnectionMissingException).

Sounds good to me. Where possible, consider using the raise from syntax. For example, the key error cases could use this. Basically, this wraps the source (key error) inside our more informative custom exception. Please feel free to add these to this PR.

Done

@EwoutH,
I am thinking of PropertyLayerDimensionException, DuplicatePropertyLayerException, and InvalidRadiusException again for mesa.discrete_space.
I have updated the discussion thread in detail. Kindly let me know your opinion.

Just a kind request: please refrain from pinging maintainers. We get the updates and try to respond as soon as we can. Sometimes, we as maintainers might ping each other because we are aware of our respective expertise across different parts of the codebase.

As discussed in the thread,
MesaSpaceException, and DimensionException has been implemented.

I like the direction this is moving in. Can you next take a look at the experimental continouous space and see what custom exception needs there might be there and how those might be integrated cleanly into this hierarchy?

If we establish DimensionException as a shared/generic error, ContinuousSpace fits in cleanly. I propose adding a ContinuousSpaceException base class and one specific logic error:

Proposed Hierarchy

MesaException
├── DimensionException (Shared: used for invalid width/height or grid shape mismatches)
├── DiscreteSpaceException
│   └── ... (CellFull, etc.)
└── ContinuousSpaceException (New Module Base)
    └── OutOfBoundsException

Rationale for OutOfBoundsException:
In a continuous space with torus=False, agents often hit the edge. Currently, we might rely on clamping or generic errors.
• Use Case: A user wants custom boundary logic (e.g., "if agent hits wall, reverse velocity" or "if agent hits wall, remove agent").
• Benefit: They can catch OutOfBoundsException to trigger this logic cleanly, rather than checking coordinates manually after every move step.

Do we need the distinction between ContinuousSpaceException and DiscreteSpaceException, or can we simplify this to just a generic SpaceException?

I'll get back to you on theOutOfBoundsException.

Do we need the distinction between ContinuousSpaceException and DiscreteSpaceException, or can we simplify this to just a generic SpaceException?

How about, as of now we implement all the exceptions we want under ContinousSpaceException and DiscreteSpaceException, then judging the number of exceptions under each branch, we decide if we want a unified SpaceException.
Or another option is, we implement SpaceException, and make ContinousSpaceException and DiscreteSpaceException inherit from it. But I think this option will make the hierarchy more complicated.

I'll get back to you on theOutOfBoundsException.

Sure.

Do we need a separate ContinuousSpaceException and DiscreteSpaceException?

Do we need a separate ContinuousSpaceException and DiscreteSpaceException?

I don't think we will need separate exceptions. I have implemented a unified SpaceException to take care of this.

@EwoutH, I am happy with how this is turning out and would be in favor of merging this as part of 4.0 while expanding the use of custom exceptions where appropriate. Would like to hear your thoughts as well before merging this.

Sorry, missed it last week. But it looks good and clean, thanks both!