In case of SBR/MBR, if a query executed on master has already modified something that cannot be rolled back, and it gets interrupted in the middle, it is written to the binlog with the corresponding error code.
When slave reaches it, replication aborts with

Query partially completed on the master (error on master: 1317) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query ...

This happens on maria/5.5 revno 3458, and of course before it too, as well as on MySQL 5.5/5.6. (5.1-based versions too, but it obviously makes no sense to touch them).

In case of SBR it is probably unavoidable. But if MBR is used, it could make sense to log such changes in row mode, which works perfectly fine (only updated rows are written, no error code is needed, replication goes as usual).

Test case
(if you have a super-fast machine, and reap succeeds instead of throwing ER_QUERY_INTERRUPTED, you might want to insert more records into t1):

--source include/master-slave.inc

--let $con1 = `SELECT CONNECTION_ID()`

CREATE TABLE t1 (pk INT AUTO_INCREMENT PRIMARY KEY, i INT) ENGINE=MyISAM;

INSERT INTO t1 (i) VALUES (1),(2),(3),(4);

INSERT INTO t1 (i) SELECT ta.i FROM t1 ta, t1 tb,

  t1 tc, t1 td, t1 te, t1 tf, t1 tg, t1 th;

--send UPDATE t1 SET i=i+1

--connection master1

--let $show_statement = SHOW PROCESSLIST

--let $field = State

--let $condition = = 'Updating'

--source include/wait_show_condition.inc

--eval KILL QUERY $con1

--connection master

--error ER_QUERY_INTERRUPTED

--reap

--sync_slave_with_master